共计 3661 个字符，预计需要花费 10 分钟才能阅读完成。
在《DistSQL：像数据库一样应用 Apache ShardingSphere》一文中，Committer 孟浩然为大家介绍了 DistSQL 的设计初衷和语法体系，并通过实战操作 展现了一条 SQL 创立分布式数据库表的弱小能力，展示了 Apache ShardingSphere 在新形态下的交互体验 。
在前文公布后，小助手陆续收到热心读者的私信，询问应用 DistSQL 配置分片规定的细节，以及应用 YAML、Namespace 等模式的配置时，是否能够像 DistSQL 一样疾速不便的实现分布式表的配置和创立？本文将为大家解答这些疑难。
江龙滔
SphereEx 中间件研发工程师，Apache ShardingSphere contributor。目前专一于 ShardingSphere 数据库中间件研发及开源社区建设。
背景
Sharding 是 Apache ShardingSphere 的外围个性，也是 ShardingSphere 最被人们熟知的一项能力。在过来，用户若须要进行分库分表，一种典型的施行流程（不含数据迁徙）如下：
图 1 Sharding 施行流程示意图
在这一过程中，用户须要精确的了解每一张数据表的分片策略、明确的通晓每张表的理论表名和所在数据库，并依据这些信息来配置分片规定。
以上述分库分表场景为例，理论的数据表散布状况可能如下：
图 2 8 库 * 4 表散布示意图
痛点
在前述的分库分表场景中，作为 Sharding 性能的用户，必须要对数据表的散布状况了然于心，能力写出正确的 actualDataNodes 规定。如上述 t_order 表对应的分片配置如下：
tables:
t_order:
actualDataNodes: ds_${0..7}.t_order_${0..3}
databaseStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: database_inline
tableStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: table_inline
shardingAlgorithms:
database_inline:
type: INLINE
props:
algorithm-expression: ds_${order_id % 8}
table_inline:
type: INLINE
props:
algorithm-expression: t_order_${order_id % 4}只管 ShardingSphere 的配置规定曾经十分的标准和简洁，但仍有用户在应用中遇到各种麻烦：
不了解分片策略或配置规定，无从下手
分片配置与数据表理论散布不匹配
配置表达式格局不正确
等等
如这位用户提出的 issue：
AutoTable 横空出世
为了帮忙用户更好的应用分片性能，升高配置复杂度和晋升应用体验，Apache ShardingSphere 5.0.0 版本推出了一种新的分片配置形式：AutoTable。
顾名思义，AutoTable 类型的数据表，交由 ShardingSphere 主动治理分片，用户只须要指定分片数量和应用的数据源，无需再关怀表的具体散布，配置格局如下：
autoTables:
t_order:
# 指定应用的数据源
actualDataSources: ds_${0..7}
shardingStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: mod
shardingAlgorithms:
mod:
type: MOD
props:
# 指定分片数量
sharding-count: 32通过以上配置，ShardingSphere 辨认出逻辑表 t_order 须要分为 32 片且应用 8 个数据源，则主动计算出 8 库 * 4 表 的散布关系，实现和传统形式等效的配置后果。
与 DistSQL 联合
通过前一节的配置比照，置信读者曾经感触到了 AutoTable 带来的改革。不过，随着 DistSQL 的公开，ShardingSphere 还能带给咱们更多。
在应用 DistSQL 进行数据管理的场景下，AutoTable 可能极大的升高分片配置复杂度。并且，与传统文件配置模式相比，通过 DistSQL 来配置分片规定是即时失效的，无需重启，这样也就齐全不必放心单张表的规定调整影响其余在线业务。
除了新增分片配置，DistSQL 也提供了批改和删除分片规定的语法，格局如下：
# 新增分片规定
CREATE SHARDING TABLE RULE t_order (RESOURCES(resource_0,resource_1),
SHARDING_COLUMN=order_id,TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=4))
);
# 批改分片规定
ALTER SHARDING TABLE RULE t_order (RESOURCES(resource_0,resource_1),
SHARDING_COLUMN=order_id,TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=10))
);
# 移除分片规定
DROP SHARDING TABLE RULE t_order;* 注：若规定批改影响到存量数据，ShardingSphere 还将提供“弹性扩缩容”的性能用作数据迁徙，帮忙用户方便快捷的治理分布式数据。无关“弹性扩缩容”的具体细节，请关注后续推送。
FAQ
Q1: ShardingSphere-JDBC 中能够应用 AutoTable 分片配置吗？
能够。AutoTable 分片配置形式实用于 ShardingSphere-JDBC 和 ShardingSphere-Proxy，在 Proxy 中更能够通过 DistSQL 进行动静配置，满足各种接入形式的须要。
Q2: AutoTable 反对哪些分片算法？
AutoTable 反对全副的主动分片算法，包含：
MOD：取模分片算法
HASH_MOD：哈希取模分片算法
VOLUME_RANGE：基于分片容量的范畴分片算法
BOUNDARY_RANGE：基于分片边界的范畴分片算法
AUTO_INTERVAL：主动时间段分片算法
对于以上算法的更多详细信息，请浏览 Apache ShardingSphere 官网文档 - 主动分片算法：
https://shardingsphere.apache…
除内置算法外，用户也能够通过 SPI 扩大的形式加载自定义的分片算法，满足更加定制化的分片需要。
Q3: 业务曾经应用了 YAML 配置分片规定，能够转换为 AutoTable 配置模式吗？
不举荐。如果是曾经存在分片规定的数据表，除非能确定切换为 AutoTable 配置后，表散布状态与预期完全一致，否则不倡议尝试切换已有配置。
不过若是在原有利用的根底上新增数据表，那么新增的表是能够应用 AutoTable 配置的。
Q4: AutoTable 的举荐应用场景？
无论是在 ShardingSphere-JDBC 还是 ShardingSphere-Proxy 中，AutoTable 都心愿为用户带来「管家式」的分片配置体验。即用户只通知 ShardingSphere 分片数量，不须要关怀理论表在哪个库、哪个库有几张表等问题。
因而，若要应用 AutoTable 配置，举荐用户忘却「先建表、再配规定」的传统思维，改为先配置规定再通过 CREATE TABLE 语句创立数据表。把 ShardingSphere 看作分布式数据库的接入点，而不是中间件。
Q5: 数据源名称不是间断的，或数量太多，能够应用 AutoTable 吗？
能够。指定数据源时并不要求名称间断，能够同时应用枚举和 INLINE 表达式，如以下模式：
CREATE SHARDING TABLE RULE t_order (RESOURCES('resource_${0..9}',resource_12,resource_15,"resource_$->{17..19}"),
...
);Q6: AutoTable 配置和传统的分片配置能够混合应用吗？
能够。请参考残缺的配置样例：
https://github.com/apache/sha…
彩蛋
GitHub ID 为 @CatYangWei 的用户第一个发现并提出了对于 AutoTable 相干的问题：
感激这位仔细的用户，咱们将会通过 GitHub 与您分割，并送上社区的精美周边。👏👏👏也欢送更多的社区小伙伴向咱们提出优化倡议，帮忙社区更好地成长～
结语
以上就是本次分享的全部内容，如果读者对 Apache ShardingSphere 有任何疑难或倡议，欢送在 GitHub issue 列表提出，也可提交 Pull Request 参加到开源社区，为社区贡献力量。
GitHub issue：
https://github.com/apache/sha…
奉献指南：
https://shardingsphere.apache…
欢送扫码关注咱们