Noamwa接了几年数据分片相关的事，大大小小的中间件都试过，Sharding-Sphere是其中之一，也是目前社区最活跃、落地场景最广的一套解决方案。很多人一听“分库分表”就觉得头大，觉得配置复杂、坑多、不敢动，其实只要把它的核心模型搞明白，把几个关键配置吃透，日常业务拆分的需求基本都能顺下来。
这篇文章不是官方文档的复读，而是把我自己在项目里用Sharding-Sphere做分片、读写分离、分布式事务的实操过程、踩坑记录、选型思考整理出来。如果你正好在调研分库分表方案，或者已经用上 Sharding-Sphere 但被某些细节卡住，这篇内容应该能帮你少走不少弯路。
1. 先搞清楚Sharding-Sphere到底解决什么问题
1.1 从单库瓶颈说起
大多数业务系统的演进路径都差不多：刚开始一个库一张订单表跑得好好的，每天几万单毫秒级响应。等到日订单量爬到百万、千万级，单表数据量过亿，你会发现几个问题同时冒出来——索引越来越深，写入锁竞争加剧，慢查询开始频繁告警。就算你花大价钱升级物理机，CPU和IO很快又会被打满，而且单库单表的容量始终是有上限的。
这个阶段最直接的做法就是分库分表，把数据按照某种规则拆到多个库里、多张表里。但分库分表说起来简单，做起来全是细节：路由规则怎么写、查询怎么跨片聚合、主键怎么保证全局唯一、扩容怎么平滑迁移，这些要是全都自己实现，没有几个月根本搞不定，而且后续维护成本极高。Sharding-Sphere 做的就是把这一整套能力封装好，让你通过配置就能完成分片。
1.2 Sharding-Sphere的核心能力与定位
Sharding-Sphere 是一个生态化的数据库中间件套件，它不是一个单一组件，而是由多个产品线组成。简单梳理一下核心能力：
- 分库分表：支持分片、广播表、绑定表，内置多种分片算法
- 读写分离：主从库读写流量分离，支持多种负载均衡策略
- 数据加密：字段级加解密，对业务透明
- 分布式事务：支持本地事务、XA两阶段提交、Seata柔性事务
- 分布式治理：配置中心、注册中心、集群管理
它在整个架构中的位置很清晰：介于应用和数据库之间，对上层应用伪装成一个标准的数据源，对下层屏蔽数据库集群的复杂性。接入方式分两种，一种是 Jar 包形式的 Sharding-JDBC，侵入在应用内，性能损耗低；另一种是独立部署的 Sharding-Proxy，对应用透明，适用于异构语言或不想修改应用的场景。
如果你正在评估要不要引入这套东西，我个人的判断是：单表超过千万级、日增数据量大、查询模式有明显分片键特征，这些场景下值得用；如果数据量还没到瓶颈，提前引入反而增加维护复杂度，没必要为了技术而技术。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 架构演进与选型思路
2.1 三个接入端的取舍：JDBC、Proxy、Sidecar
Sharding-Sphere 提供的接入方式有三种，很多人一开始搞不清选哪个。我实际用下来，它们各有适用边界，不是简单的谁替代谁的关系。
Sharding-JDBC 是一个轻量级 Jar 包，在应用侧以数据源的形式工作。它直接用 JDBC 协议连接各个数据库节点，应用代码里只需要把数据源替换成 ShardingDataSource 即可。最大优势是性能好，因为没有额外的网络转发层，分片路由逻辑直接跑在应用进程内。劣势是每个接入的应用都要引入依赖并维护配置，如果微服务很多，改动量会翻倍。
Sharding-Proxy 则是一个独立部署的代理服务，对客户端暴露一个标准 MySQL/PostgreSQL 协议端口。应用完全感知不到后端的数据库集群，连接 Proxy 就像连接一个普通数据库。它适合多语言异构系统，也适合 DBA 统一管控的场景。代价是多了一跳网络转发，性能有一定损耗，并且线程模型需要额外调优。
Sidecar 形态目前更多是在特定云原生环境中使用，日常业务系统用得少。我的建议很简单：Java 技术栈、追求极致性能、团队有能力维护配置，直接用 JDBC；跨语言、需要快速接入、不想改应用代码，优先考虑 Proxy。如果团队规模大、希望统一治理，Proxy 的运维收益会逐渐超过性能损耗。
2.2 版本升级关键点：4.x到5.x到底变了什么
如果你翻过老版本的资料，会发现 Sharding-Sphere 的配置风格在新版本里变化很大，这也是很多新手看教程觉得混乱的原因。
4.x 时代用的是基于 YAML 的“表规则 + 分片算法”松耦合配置，直接写在 shardingRule 节点里，语法相对冗长。5.x 之后配置大幅简化，引入了 rules 和 props 分层结构，分片算法支持 SPI 方式注入，也支持纯表达式配置，同时内核重构为可插拔的 SQL 解析引擎、路由引擎、改写引擎、执行引擎、归并引擎 五层结构。
从 4.x 升到 5.x 有一个点必须留意：旧配置里的 defaultDatabaseStrategy、defaultTableStrategy 在新版本中调整了语义，分片算法的配置写法也从 inline 表达式改为更严格的 CLASS_BASED 或 INTERVAL 等类型声明。还有，老版本的强制路由 HintManager 在 5.x 中 API 有调整，如果你用到了强制路由，升级时一定要回归测试这部分。
我把两个版本的核心差异整理成一个对照表，方便你迁移时核对：
| 对比项 | 4.x 风格 | 5.x 风格 |
|---|---|---|
| 配置结构 | shardingRule 单一节点 | rules 多规则分层 |
| 分片算法配置 | inline 表达式为主 | CLASS_BASED / INTERVAL / HASH_MOD |
| 读写分离 | 独立 masterSlaveRule | readwrite-splitting 独立规则 |
| 分布式事务 | 依赖外部事务管理器 | 内置 XA / Seata 集成 |
| 内核扩展 | 定制能力较弱 | SPI 可插拔，扩展点丰富 |
如果你刚接触，直接按 5.x 的语法学习就行，不要再去看 4.x 的资料。如果已经在生产用了 4.x，也别急着大改，先在测试环境把配置和核心 SQL 回归验证一遍再升级。
3. 分片配置实操指南
3.1 一套完整的分片配置长什么样
配置是 Sharding-Sphere 的核心，也是最容易出错的地方。我以订单表做水平分表的场景为例，给你一套可以直接参考的 YAML 配置。
订单业务我们当时拆成 4 个库，每个库 4 张表，分片键是 order_id，分片算法用的哈希取模。下面是 5.x 版本的配置结构：
yaml复制rules:
- !SHARDING
tables:
t_order:
actualDataNodes: ds_${0..3}.t_order_${0..3}
tableStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: t_order_hash_mod
keyGenerateStrategy:
column: order_id
keyGeneratorName: order_snowflake
shardingAlgorithms:
t_order_hash_mod:
type: HASH_MOD
props:
sharding-count: 4
keyGenerators:
order_snowflake:
type: SNOWFLAKE
props:
worker-id: 1
props:
sql-show: true
这段配置的语法看起来简单，但有几个细节需要注意。actualDataNodes 用的是 Groovy 表达式展开，ds_${0..3} 会解析成 ds_0、ds_1、ds_2、ds_3，表名同理。分片键 order_id 必须出现在查询条件的 WHERE 中，否则会走全路由，把四个库的表全部查一遍，性能直接崩掉。
HASH_MOD 算法就是 order_id % sharding-count，但这种简单取模有个很大的问题：一旦表数量变化，数据分布会全部打乱。所以生产环境我通常建议用 HASH_MOD 的变体配合固定分片数量，提前预留好扩展空间，不要频繁改分片数。
真正把配置落地的时候，你还得考虑单表分片和分库分表的区别：如果只在单库内分表，actualDataNodes 写成 ds_0.t_order_${0..3} 即可；如果要分库，每个库的表名规则要一致，否则路由会报错。
3.2 分片算法的选择与场景匹配
Sharding-Sphere 内置了多种分片算法，选型直接决定后续性能和扩展性，这里我按实际场景帮你梳理一下。
INLINE 表达式是最简单的一类，适合通过简单的 Groovy 表达式做分片，比如 ds_${order_id % 2}。优点是写起来快，缺点是不支持复杂的范围查询，并且如果表达式写错，运行期才会暴露，测试要覆盖到位。
STANDARD 标准分片是我们用得最多的，分为精确分片和范围分片两部分。精确分片负责 = 和 IN 查询，范围分片负责 BETWEEN AND 和 >、< 查询。这里有个关键点：范围分片算法如果不实现，那么范围查询就只能全路由扫描，性能会很差。所以只要业务里可能用到范围查询，就一定要把范围分片实现掉。
COMPLEX 复合分片适合多个分片键联合路由的场景，例如同时根据 order_id 和 user_id 路由。实现 ComplexKeysShardingAlgorithm 接口时，可以拿到所有分片键的值集合，然后自定义路由逻辑。这块自由度最高，但也最容易出错，建议在单元测试里把边界条件写全。
HINT 强制路由适合分片键不在 SQL 中出现的场景，比如按登录用户 ID 分片但查询条件不带该字段，这时候可以通过 HintManager 在代码里指定目标数据源/表。我一般只在特定报表查询场景使用，业务主链路尽量不用，因为它会破坏 SQL 自治性，增加维护成本。
给你一个选型参考表：
| 算法类型 | 适用场景 | 注意事项 |
|---|---|---|
| INLINE | 简单的等值查询分片 | 不支持范围查询，表达式要谨慎 |
| STANDARD | 等值 + 范围查询混合 | 必须实现范围分片算法 |
| COMPLEX | 多分片键联合路由 | 路由逻辑复杂度高，需充分测试 |
| HINT | 分片键不在 SQL 中 | 侵入业务代码，最后手段 |
3.3 分布式主键生成方案对比
分库分表后，数据库自增主键就失效了，因为多个库的自增 ID 会冲突。这时候分布式主键的选型尤为重要，Sharding-Sphere 内置了 UUID 和 SNOWFLAKE 两种方案，也支持自定义。
UUID 虽然实现简单，但生成的 ID 是字符串且无序，作为主键会带来两个问题：一是存储空间变大，索引性能下降；二是无序插入会导致 B+ 树频繁页分裂，写入性能被拖累。所以我基本不会用 UUID 做订单这类核心表的主键，只会在日志、异步消息等表中使用。
雪花算法是目前的主流选择，生成的是一个 64 位 Long 型 ID，趋势递增，性能极高。Sharding-Sphere 的 SNOWFLAKE 实现支持 worker-id 配置，同一个服务多实例部署时必须给每个实例分配不同的 worker-id，否则会生成重复 ID。如果你用的是默认配置，它内部会尝试从网卡 MAC 地址或 IP 解析，但在容器环境下很容易解析出错，所以显式配置 worker-id 是最稳妥的做法。
还有一个经验是：分片键和主键直接使用同一个雪花 ID，这样既能保证全局唯一，又能通过主键直接路由到目标分片，省去额外查询分片键的成本。这个设计在订单详情查询、按 ID 精确查询里收益非常明显。
如果你的自研框架有现成的分布式 ID 服务，也可以实现 KeyGenerator 接口接入，Sharding-Sphere 支持 SPI 方式注入自定义主键生成器，灵活度很高。
4. 读写分离配置实践
4.1 配置主从规则时容易忽略的细节
分库分表之后，很多业务的读压力依然很大，读写分离是自然的下一步。Sharding-Sphere 的读写分离配置在 5.x 里独立成 READWRITE_SPLITTING 规则，和分片规则可以同时存在。
简单配置示例：
yaml复制rules:
- !READWRITE_SPLITTING
dataSources:
readwrite_ds:
writeDataSourceName: ds_master
readDataSourceNames:
- ds_slave_0
- ds_slave_1
loadBalancerName: round_robin
loadBalancers:
round_robin:
type: ROUND_ROBIN
配置本身不难，但有几个细节常被忽略。首先是主从同步延迟问题，Sharding-Sphere 不会感知主从之间的数据同步状态，如果你在写入后立即查询，走到从库可能读到旧数据。解决方式有几种：关键业务读写都走主库（通过 HintManager 强制路由），或者对延迟敏感的表不做读写分离，也可以引入延迟阈值检测，超过阈值的从库临时摘除。
其次是事务内路由问题，默认情况下同一个事务里的所有 SQL 会路由到主库，这没问题。但如果你用了 @Transactional 且内部既有读又有写，Sharding-Sphere 会把事务内的读请求也绑定到主库，避免脏读。这个行为是合理的，但很多人会遇到疑问：为什么事务里开了读操作，从库一点都不分担压力？答案就在这里。
还有一个容易踩的坑：如果从库挂了或者同步异常，读写分离并不会自动切换，只会在负载均衡时选择可用的从库。建议在从库层面做高可用监控，配合数据库主从切换机制使用，而不是依赖 Sharding-Sphere 来做故障转移。
4.2 负载均衡与同线程数据一致性
读写分离的负载均衡策略主要有 ROUND_ROBIN、RANDOM、WEIGHT 几种，Sharding-Sphere 默认支持轮询和随机。实际生产我建议用权重策略，把机器配置高的从库分配更多流量，机器配置低的减少流量，避免负载不均。
同线程数据一致性是一个容易被忽视的高级话题。默认情况下，同一个线程内如果没有开启事务，每次查询都会独立选择数据源，可能出现第一次查主库、第二次查从库的情况。如果你在业务代码里依赖 ThreadLocal 做状态传递，或者在一个请求内有“先写后读同数据”的逻辑，一定要明确控制路由策略。
Sharding-Sphere 提供了 HintManager 的 setWriteRouteOnly 方法，可以在代码层面强制某个查询走主库。我在“下单后立即查订单详情”这个场景就用了这个方案，效果很直接，避免了主从延迟带来的体验问题。但注意 HintManager 使用后必须调用 close()，否则 ThreadLocal 里残留的强制路由状态会影响后续请求，这是一个非常隐蔽的坑。
5. 分布式事务处理方案
5.1 几种事务模式的适用边界
分库分表之后，跨库事务成为绕不开的问题。如果业务对一致性要求极高，比如资金类操作，需要使用分布式事务方案；如果业务可以容忍短暂不一致，用最终一致性方案更轻量。
Sharding-Sphere 对分布式事务的支持分几个层次。本地事务就是普通的事务，但它只能保证单个分片内的一致性，跨分片就无法保证，这在业务里只适合纯单分片操作。XA 两阶段提交是传统的强一致方案，Sharding-Sphere 内置了 Atomikos 和 Narayana 的集成，通过 @Transactional 注解即可使用，实现简单，但性能开销大，数据库资源被事务管理器长时间锁定，高并发下容易成为瓶颈。
Seata 柔性事务是 Sharding-Sphere 目前主推的方向，支持 AT 模式和 TCC 模式。AT 模式通过拦截 SQL、生成 undo_log 来实现回滚，对业务侵入最小；TCC 模式则需要业务自己实现 Try/Confirm/Cancel 三个方法，控制更精细但开发量大。
我个人的选型原则是：资金交易、强一致要求用 TCC 或 XA；一般的订单流程、积分变动这类最终一致性可以接受的场景，直接用 Seata AT 模式；单分片内的简单业务，用普通本地事务就够了，别动不动就上分布式事务，性能代价是实打实的。
5.2 基于Seata AT模式的整合实践
Sharding-Sphere 集成 Seata 的配置路径比较清晰，但有几个细节不踩不知道。首先需要在 seata.conf 里定义事务组和注册中心的地址，然后在 Sharding-Sphere 的 YAML 配置里开启事务类型：
yaml复制props:
transaction-type: SEATA
同时引入依赖：
xml复制<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-transaction-base-seata-at</artifactId>
<version>${shardingsphere.version}</version>
</dependency>
实际跑起来之后，我发现 Seata AT 模式有两个坑值得注意。
第一个是 undo_log 表必须提前在每个分片库里创建好，否则事务执行时报错而且日志不明显。这个表可以手动建，也可以用 Seata 提供的脚本统一创建，务必保证所有分片库都建好。第二个是 Seata 的全局锁机制在高并发下会出现锁等待超时，典型表现是事务执行时间变长、接口 RT 突增。解决思路是：缩小事务边界、减少跨分片更新冲突，或者调整 Seata 的全局锁重试参数。
还有一个容易被坑的地方：Seata AT 模式依赖数据库的 JDBC 代理来实现 SQL 拦截，如果你在代码里用了 JPA 的二级缓存，或者手写了原生 SQL，可能会绕过 Seata 的拦截，导致回滚失败。遇到这种情况，一个稳的做法是主链路不用二级缓存，SQL 尽量走简单标准写法。
6. 常见问题排查与性能调优实录
6.1 分片场景下的SQL兼容性坑
先说一个最容易遇到的问题：SQL 里带 ORDER BY 和 LIMIT 的时候，Sharding-Sphere 的分片结果归并逻辑可能跟你预期不一样。默认情况下，分片后会把各分片查询结果拉到一个归并引擎里排序，如果你的 LIMIT 很大，比如 LIMIT 100000, 20，内存里需要承载所有分片返回的大量行，性能必然下降。这种情况下优化思路是：尽量用分片键过滤缩小结果集，或者把深分页改成游标分页，用 WHERE id > ? ORDER BY id LIMIT 20 这种形式。
聚合函数也有兼容性坑，例如 COUNT(*) 在多分片下需要各片分别统计再汇总，这个 Sharding-Sphere 能正确处理。但 DISTINCT + ORDER BY 的组合在一些老版本里会有排序丢失的问题，升级到 5.x 之后问题少了很多，不过日志里如果出现 Unsupported operation 还是要注意。
还有一类很容易踩的是子查询。Sharding-Sphere 对简单子查询支持还行，但嵌套过深的子查询或 IN (SELECT ...) 这种结构，有可能在解析阶段直接报错，或者路由结果不符合预期。遇到这种情况，我通常会手动改写 SQL，把子查询拆成两条查询，在业务代码里做结果合并。虽然多一次网络交互，但稳定性和可排查性都会好很多。
另一类常见问题是表名大小写和反引号。MySQL 里如果建表用了反引号包裹，Sharding-Sphere 的解析器可能无法正确识别表名，导致路由失败。建议统一使用小写表名，并且不要显示写库名前缀，SELECT * FROM db.t_order 这种写法有时候会让路由引擎误判表归属。
6.2 连接池耗尽与内存溢出排查
分库分表之后，连接池的数量会成倍增加。假设原来一个数据源 20 个连接，现在拆成 4 库每库 20 个连接，总连接数就是 80。如果服务的连接池配置还是按单库逻辑来，很容易出现连接不够用的情况。
我遇到过最典型的问题是：某个服务把 Druid 的 maxActive 配置成 50，分 4 个库后每个连接池的 50 并不等于总体 50，实际是 200，数据库服务端的最大连接数直接被占满，其他应用连不上去。排查了半天，最终是在数据库端查到大量 sleep 连接才定位到。这里建议：连接池配置要按分片后的单库来评估，同时给数据库设置好 max_connections 并接入连接数监控告警。
内存溢出则是归并引擎的锅。如果你在一条 SQL 里查了全分片且没有加分页，比如 SELECT * FROM t_order WHERE status = 1 且没有分片键，Sharding-Sphere 会把四个分片的结果集全部加载到内存归并，数据量大时直接 OOM。遇到这种场景，一个是坚决避免无分片键的全表查询，另一个是在 SQL 里强制加 LIMIT，并确认归并引擎走的是流式归并而不是内存归并。
流式归并和内存归并的区别在于：流式归并只在内存中保留每条数据流的一行，适合 ORDER BY 排序的场景；内存归并则需要全部结果集参与，适合聚合或需要全文排序的场景。5.x 默认会根据 SQL 类型自动选择，但如果你手动开启了某些配置，可能在 ORDER BY 场景误走了内存归并，内存占用飙升。可以通过 sql-show 打开日志，查看执行计划里每个分片的查询语句和归并方式。
6.3 分片扩容与数据迁移的实战总结
分片之后最让人头疼的就是扩容。早期如果用了 HASH_MOD 这种简单取模，扩容时数据需要重新分布，停服务迁移是常规操作，但业务不可接受。所以我的建议是：分片设计之初就给未来留余地，不要贪图省事用简单取模。
常见的可扩展设计有两种。一种是用一致性哈希，比如 org.apache.shardingsphere.sharding.algorithm.sharding.classbased 里自定义实现，或者使用内置的 HASH_MOD 但把分片总数固定在较大的值，比如提前分成 1024 个逻辑分片，再映射到 8 个物理库。这样扩容时只需要迁移部分逻辑分片的物理位置，数据迁移量大大减少。
另一种是用时间维度分表，比如按月分表，业务上只保留最近三个月的数据热访问。这种方案对时序类数据非常友好，天然支持平滑扩容：新月份自动生成新表，不需要迁移旧数据。缺点是查询必须带上时间范围，否则会查全表，跨月查询需要用视图或者代码层做合并。
我实际做过一次 4 库 4 表到 8 库 8 表的扩容，流程大概分几步：
- 在测试环境用数据工厂生成全量历史数据，生产开启同步工具做增量同步
- 通过自定义迁移脚本把旧分片的数据按新分片规则重新计算目标节点，写入新库
- 业务代码先开启双写一段窗口期，新老数据同时写，校验两边数据一致
- 切换只读流量到新库，跑核心链路回归，确认无问题后切换写流量
- 观察监控一段时间，确认稳定后下线旧库
整个过程最耗时的是数据校验环节，因为数据量大、分片规则有变化，不能只校验总数，而要核对每个分片键的分布情况。建议写一个核对脚本，按逻辑分片做抽样比对，重点看边界值附近的数据。
6.4 分布式治理与配置中心选型
Sharding-Sphere 从 5.x 开始把治理能力提到了比较重要的位置，支持接入 ZooKeeper、Nacos、Etcd 等配置中心和注册中心。如果你有多实例部署，配置不让它自动广播的话，每次改配置都要同步到所有节点，累也容易出错。
我这边用的 Nacos，配置中心里维护了 sharding.yaml 的 DataId，服务启动时动态拉取并监听变更。这样调整分片算法或读写分离权重的时候，只需要改 Nacos 上的配置，然后触发一次发布，服务会自动感知并重新加载规则，不需要重启 Java 进程。
但配置变更虽然方便，也有风险。比如你改了一个分片算法，运行中的连接池不会立刻回收，新的 SQL 可能已经被新规则路由了，这时候会出现“新旧规则同时存在”的过渡期。所以在生产环境做任何规则变更，都建议先在有流量的灰度环境观察，再逐步推全量，不要图快一键发布。
配置中心的另一个作用是存 props 级别的参数，比如 sql-show 是否开启、executor-size 线程池大小。这些参数线上调优的时候经常要改，放配置中心里可以省去大量部署操作。
7. 一些关于踩坑和选型的碎碎念
最后再分享几个我在真实项目里积累的体会。
第一个是不要神话 Sharding-Sphere。它确实解决了分库分表的大部分通用问题，但并不是所有问题都能接管。比如跨分片的 JOIN，虽然它支持绑定表来优化，但本质上还是需要额外的内存操作，性能远不如单库。设计表结构的时候必须提前考虑分片键的选择，把高频查询尽量压到单个分片上。
第二个是 SQL 规范要提前定好。我在项目里强制要求所有人遵守：查询必须带分片键；禁止 SELECT *；LIMIT 必须有上限；不允许在 SQL 里做复杂运算或存储过程调用。这样做的原因很简单，Sharding-Sphere 的 SQL 解析和改写能力再强，也架不住业务把查询写成天马行空的样子，限制 SQL 能避开绝大多数兼容性坑。
第三个是监控告警要跟上。分片之后的监控维度不再是单库的，而是需要按库、按表、按分片键的访问分布来看。比如某个分片节点比其他节点慢很多，有可能是数据倾斜，有可能是连接池参数问题。建议把每个分片节点的慢查询、连接数、QPS 指标单独打点，在监控面板上做聚合对比，任何异常都能第一时间发现。
第四个是团队培训和文档沉淀。分片中间件对团队来说是一个长期维护的知识体系，光靠两三个人懂是不够的。我习惯把每次线上故障和排查过程写成文档，沉淀成团队内部的排查手册，新人来了照着手册就能上手，而不是拿着文档啃官方文档。
Sharding-Sphere 不是万能的，但它确实是目前 Java 生态里分库分表和分布式数据库中间件绕不开的选择。你把它理解成一套优雅的规则引擎，把数据分布、路由、聚合这些脏活累活都封装在配置层，剩下的事就是业务侧把 SQL 规范做好。只要分片键设计合理，配置中心搭起来，事务方案选对，这套体系在亿级数据量下依然能跑得很稳。
我踩过的坑不少，最深的体会就一句话：分片方案好不好，往往不在上线那一刻，而在半年后第一次扩容、第一次加新业务查询的时候。所以从一开始就把规则设计得有余量、把 SQL 管得够严格，后面才不会被追着改代码。