纪环从“单库扛不住了”到“分库分表落地”：一次基于MySQL + ShardingSphere的完整实践笔记
大概两年前，我接手了一个后台系统，业务逻辑不算复杂，但数据增长实在吓人。订单表三个月涨了快两千万行，单表查询已经明显发飘，稍微带个范围条件的统计查询，数据库CPU直接飙到80%以上，慢查询日志里全是全表扫描。更麻烦的是，单库的写入瓶颈也出来了，高峰期插入一条订单都要等几百毫秒。说白了，单机MySQL的容量和性能上限已经把系统按在地上摩擦了。
当时团队讨论过几个方案：先说缓存，但缓存只能解决热点读，解决不了写瓶颈，更解决不了数据量增长后的存储和备份压力；再说分库分表，这个方向从一开始就是明确的，真正纠结的是怎么分、用什么中间件、以及上线之后怎么保证数据一致性和查询兼容性。
最终我们选定了ShardingSphere，准确说是ShardingSphere-JDBC，配合MySQL 8.0，完成了订单、订单明细、支付流水三张核心表的分库分表改造。这篇文章就围绕这次改造，把整个过程中的方案选型、分片规则设计、数据迁移、存量数据清理、灰度上线、常见故障排查一次讲清楚。如果你正准备做分库分表，或者已经在做但踩了不少坑，这篇文章应该能帮你省下不少时间。
1. 为什么最终选了ShardingSphere，而不是MyCat或自研中间件
先聊选型。分库分表中间件目前市面上用得多的就那几类：以ShardingSphere为代表的客户端模式，以MyCat为代表的代理模式，以及大厂内部自研的种种方案。我们当时认真对比过，也做了小规模压测，说说我的实际感受。
1.1 ShardingSphere-JDBC与MyCat的本质区别
很多人第一次接触这两个项目时会混淆，以为它们解决的问题一样，只是实现方式不同。其实差别非常大。
ShardingSphere-JDBC是以jar包形式嵌入应用进程内的，应用通过它访问数据，它内部帮你路由到具体哪个库、哪张表。应用和数据库之间没有额外的网络跳点，数据分片逻辑在你自己的服务里完成。这种模式最大的优点就是性能损耗极低，因为省掉了一层网络代理，而且配置灵活，可以在代码里精确控制每一次查询的路由行为。
MyCat则是独立部署的代理服务，应用连接的是MyCat，由MyCat再把SQL转发给后端的MySQL实例。好处是应用无感知，数据库连接管理、读写分离、分片规则都在代理层统一处理，业务方甚至不需要改代码。但缺点也很明显：多一跳网络，延迟明显增加；代理节点是单点，得自己做高可用；SQL兼容性有时候会踩坑，某些复杂的关联查询会被代理层“翻译”出问题。
我们当时为什么要选客户端模式？核心原因有两个：
第一，我们的应用是Java技术栈，ShardingSphere-JDBC对Java应用的侵入方式非常自然——引入依赖，替换数据源对象即可，不需要额外维护代理集群。第二，我们的查询场景里有很多多表关联和子查询，放在代理模式下容易出现兼容性坑，而ShardingSphere-JDBC因为是在应用层直接拦截SQL，对复杂SQL的支持度要好得多。
1.2 为什么不建议团队自研分库分表中间件
我也见过一些团队，觉得引入中间件太重了，或者想“一劳永逸”地自研一套分库分表框架。我的看法是：除非你的团队有非常强的数据库内核或分布式系统背景，并且有半年以上的专项时间，否则千万别碰自研。
分库分表看似只是“取模路由”，但实际上有很多隐含问题：跨库事务怎么办？分布式主键用什么方案？扩容时数据怎么迁移？分页排序怎么处理？多表关联查询怎么优化？范围查询怎么路由？这些问题每一个都够写几篇论文的。ShardingSphere经过这么多年的迭代，这些坑基本都已经填平了，把它拿来用，本质上是在享受开源社区的红利。
提示：选型时别忘了看团队的技术能力栈。如果团队对Java不熟，那客户端模式的学习成本可能比代理模式还高，这时候选MyCat或ShardingSphere-Proxy反而更合适。
1.3 我们最终的技术组合
我们最终确定的技术组合如下：
- 数据库：MySQL 8.0.28，存储引擎InnoDB，字符集utf8mb4
- 中间件：ShardingSphere-JDBC 5.1.2（当时最新稳定版）
- 分片算法：订单号取模 + 时间范围结合的双分片策略
- 分布式主键：ShardingSphere内置的雪花算法（Snowflake）
- 部署方式：4个MySQL实例，每个实例下8张分表，总共32张物理分表
这个组合跑了一年多，整体稳定。下面进入到核心配置环节。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分片规则设计：为什么订单号取模还不够，还要叠加时间维度
分库分表最核心的一个环节就是分片键和分片算法的设计。这一步一旦定错，后面改起来极其痛苦，甚至需要数据重迁移。我们针对订单表场景，做了大量推演后最终确定了“user_id+order_id复合策略”。
2.1 选user_id做分片键，还是order_id？
订单表最典型的查询场景有两类：一是用户查自己的订单列表，通常按创建时间倒序分页；二是后台运营查一笔订单的详情，通常是按订单号精确查询。
如果只按user_id分片，用户查询订单列表可以被路由到单库单表，效率极高。但订单详情查询的时候，如果只知道order_id而不知道user_id，就得全库全表扫描，这在生产环境绝对不能接受。
如果只按order_id分片，订单详情查询非常舒服，一次路由到位。但用户查自己的订单列表时，因为不确定这个用户的订单分散在哪些分片，只能对所有分片发起查询，然后在内存中做归并和排序，分页越深性能越差。
我们最终的方案是：订单表同时冗余user_id和order_id两个字段，分片键用order_id的取模结果，但查询用户订单列表时，在SQL条件里同时带上user_id。听起来有点绕，细说一下：ShardingSphere支持多分片键，你可以配置用户查询时用user_id路由，订单详情查询时用order_id路由。但在实际配置里，一张表只能有一个主分片键，我们最终选择order_id作为主分片键，因为精确查询订单详情的频率更高，而且必须一次定位；用户订单列表查询则通过一个特殊设计来解决——在分片算法里同时考虑user_id。
这里有个实现细节：我们的order_id生成规则是“时间戳+用户ID后四位+随机数”。通过时间戳高位可以大致判断订单时间，通过用户ID后四位可以辅助定位。当用户查询订单列表时，如果条件里没有order_id，就退化为按user_id后四位所在的几个分片做并行查询，而不是全库表扫描。
2.2 为什么要在取模基础上叠加时间维度，形成双分片维度
纯取模分片有一个很经典的问题：随着时间的推移，数据分布会越来越不均匀。因为用户增长的规律是不确定的，活跃用户集中产生的数据量远大于沉默用户，如果按user_id取模，某些分片会被打得很满，某些分片却很闲。而且，一旦需要扩容，把分片数从32变成64，所有数据都得重新路由迁移，这个成本很高。
我们借鉴了“分片+分区”的思路：在取模分片的基础上，每个物理分表内部再按月份做分区。也就是说，路由时先按order_id取模定位到具体的物理分表，再按订单时间定位到该表内部的月份分区。
这样做的直接好处是：
- 时间维度的数据天然具备局部性，冷热数据自动分离，历史数据可以按分区归档。
- 某些范围查询（比如查最近三个月的订单），可以先按时间分区裁剪，再路由到少量分片，查询性能大幅提升。
- 后续如果要清理历史数据，直接DROP分区就行，不会影响在线业务。
2.3 分片算法的核心配置示例
ShardingSphere 5.x的配置风格是YAML驱动。下面是我们订单表分片配置的一个简化版本，跑了很久没出过问题。
yaml复制rules:
- !SHARDING
tables:
t_order:
actualDataNodes: ds$->{0..3}.t_order_$->{0..7}
tableStrategy:
standard:
shardingColumn: order_id
shardingAlgorithmName: order_table_inline
keyGenerateStrategy:
column: order_id
keyGeneratorName: snowflake
auditStrategy:
auditorNames:
- sharding_key_required_auditor
allowHintDisable: true
shardingAlgorithms:
order_table_inline:
type: INLINE
props:
algorithm-expression: t_order_${order_id % 32}
keyGenerators:
snowflake:
type: SNOWFLAKE
props:
worker-id: 1
有几个细节要展开说。
actualDataNodes: ds$->{0..3}.t_order_$->{0..7}的含义是，你有4个数据源ds0到ds3，每个库里有t_order_0到t_order_7共8张表，总共32张物理表。分片表达式是order_id对32取模，结果是0到31，ShardingSphere会自动把数据路由到对应的库和表。注意这里其实隐含了一个小坑：4个库8张表，但ds$->{0..3}和t_order_$->{0..7}的顺序组合时，库和表并不是完全均匀的映射关系，实际分布类似于：order_id % 32 = 0 -> ds0.t_order_0，= 1 -> ds1.t_order_1，= 8 -> ds0.t_order_0，这就会导致同一张表落在同一个库里没问题，但如果你期望的是四库的真正负载均衡，这个表达式并不完美。要想做到真正的均匀，通常会把库和表拆成分库键和分表键两个维度分别计算。
我在实际项目中修正后的配置是：
yaml复制shardingAlgorithms:
order_ds_inline:
type: INLINE
props:
algorithm-expression: ds$->{order_id % 4}
order_table_inline:
type: INLINE
props:
algorithm-expression: t_order_${(order_id / 4) % 8}
这个表达式相当于先按order_id对4取模确定库，再按order_id除以4后对8取模确定表。这样order_id为0到31的订单会均匀分布在4个库、每库8张表中。如果你直接用一次取模order_id % 32然后靠表达式把结果隐式映射到库表，实际上分布是均匀的，也能用，但后续要调整分片数时，区分库维度与表维度会更清晰。
2.4 分布式主键为什么选雪花算法
分库分表之后，自增主键就彻底失效了，因为每个库的sequence独立，会产生重复主键。我们选用了ShardingSphere内置的雪花算法，原因很简单：
- 它是趋势递增的，对MySQL的InnoDB索引写入相对友好，不会因为随机主键导致页分裂严重。
- 生成的ID是64位Long类型，包含时间戳、机器ID和序列号，可以反解出大概的生成时间。
- 不依赖额外的中心化组件（比如Redis或ZK），应用本地就能生成，性能极高，适合高频写入场景。
不过雪花算法也有个需要留意的点：时钟回拨问题。如果服务器NTP时间回拨，就可能导致生成的ID比之前小，出现主键冲突。我们在实践中给ShardingSphere的雪花算法配置里加了时钟回拨容忍逻辑，具体表现为：如果检测到回拨，就等待一小段时间，然后继续生成。这个在高并发场景下几乎没有影响，但能力上确实兜住了底。
2.5 分片键必须出现在SQL里，这是铁律
这一点如果你没经历过生产故障，可能感知不深。ShardingSphere路由的核心依据就是分片键的值，如果一个SQL条件里没有分片键，它只能全库全表扫描，把每个分片的数据捞出来再归并。在测试环境数据量小感觉不出来，一到生产环境，慢查询直接炸掉。
我们给所有mapper加了强制约定：
- 订单详情查询必须传order_id。
- 用户订单列表查询必须传user_id。
- 后台管理列表查询如果只有时间范围，必须走ES或临时汇总表，不走分片表。
同时开启ShardingSphere的sharding_key_required_auditor审计功能，遇到没有分片键的SQL会直接报错阻断，防止底层慢查询悄悄发生。这个配置在生产环境强烈建议打开，牺牲一点灵活性，但能避免大事故。
3. 从单库到分库分表：存量数据迁移与双写方案
分片配置改完之后，真正的难关来了：存量数据怎么迁移？迁移期间线上业务不能停。我们采取的方案是“历史数据迁移 + 增量双写 + 校验补偿”三步走。
3.1 迁移工具选型：为什么用DataX而不是mysqldump
先看数据量级：订单表当时有近6000万行，订单明细表更多，快1.2亿行。这么大的量，用mysqldump导出再导入的方式显然不现实，且不说导出耗时，光是把数据重新分片写入新库新表，就需要一个能感知分片规则的导入工具。
我们最终用的是DataX（阿里开源的离线数据同步工具）。DataX把数据从MySQL读出后，可以通过自定义writer或脚本按order_id计算目标分片，写入对应库表。DataX的通道并发和流控都做得比较成熟，支持断点续传，对数据库源和目标的连接数控制也人性化，不至于把源库打挂。
不过DataX在将数据写入ShardingSphere管理的分片表时有一个坑：它默认是JDBC直连MySQL的，不会走ShardingSphere的路由逻辑。所以我们在迁移时没让DataX直接写分片表，而是写到一个“分片路由表”的中间层，或者是先按分片规则手动拆分成32个导入文件，再并发导入。听起来麻烦，但反而可控。
3.2 历史数据迁移的具体步骤
我们的迁移步骤大概如下：
- 在4个新库中分别创建好8张表结构，索引、约束、分区策略一次性建好。
- 从源库按order_id区间分批读取数据，每批5000条，放入内存队列。
- 用代码计算order_id对应的目标库和表，直接拼接JDBC写入目标库。
- 每完成一批，更新迁移进度表，记录当前已经迁到哪个order_id区间。
- 迁移结束后，按order_id总数和状态字段做计数校验，然后再随机抽样明细比对。
这里最关键的是第2步的批量读取方式。如果你的源库订单表已经很大，直接用SELECT * FROM t_order WHERE create_time > '2023-01-01'扫全表，索引基本帮不上忙，会加大对线上库的压力。我们改成按主键区间分页扫，每页只取主键和少量字段，再根据主键回表查明细，效果好了很多。
3.3 增量双写：从老系统切到新系统不丢一条数据
数据迁移期间，线上订单还在继续写入旧库。如果只做一次性全量迁移，从迁移开始到切换这段时间产生的新订单会丢。解决办法是双写，更准确地说，是在应用层做一个开关：在服务里同时写旧库和新库。
我们当时的实现方式是：在订单创建的service层加了一个配置项dual_write_enabled，打开后每次插入订单，同时写入旧表和新分片表，写入新表时直接调用新的分片逻辑。为了防止双写导致的事务问题，这里的关键在于两条write链路不能放在同一个本地事务里，否则新库写入失败会回滚掉旧库的成功操作。
我们的做法是：
- 旧库写入为主链路，保持原有事务。
- 新库写入通过事务消息或本地消息表异步执行，确保最终一致。
- 新库写入失败时，记录一条补偿日志到本地文件，补偿任务每隔5分钟重试一次。
双写开启两周后，我们对比了两边数据，确认无差异，才正式切流量。这里也踩过一个坑：双写期间，新库的分片规则如果配置错误，会导致某些order_id写入失败，而且代码里容易忽略异常，只打日志不抛出，结果就是新库数据缺了一部分，校验的时候才发现。所以双写期间一定要配置监控和告警，对每一条异步写入的失败情况都要有感知。
3.4 切换后的回滚预案
这是一个必须提前想清楚但往往被忽视的问题：如果切换后新系统出了大故障，怎么回滚？
我们设计了双活回滚方案。新系统上线后，旧库仍然保留，应用层通过配置中心控制读写走新库还是走旧库。一旦发现新库写入异常或查询超时，可以在一分钟内把流量全部切回旧库。
但要保证切回旧库后数据不丢，双写机制必须持续运行一段时间，而不是切换当天就关闭。我们实际保留了双写近一个月，直到新系统连续稳定运行，才逐步淘汰旧的写入链路。这个时间窗口越长，回滚保险系数越高。当然，双写会带来一定的硬件和代码复杂度，属于过渡期的高昂成本，但比起出故障时抓瞎，这笔投入值得。
4. 分库分表后的查询改造与常见SQL陷阱
分库分表改造，最难的不是写数据，而是读数据。很多原本在单库上很简单的SQL，在分片后会变得非常“昂贵”。这章专门讲查询改造的实战。
4.1 不带分片键的查询：全路由问题
前面说过，不带分片键的查询会触发全库表扫描。如果只是偶尔一次后台查询还能忍，但如果是高频接口，这就是事故。
我们拿用户订单列表举例。假设查询条件是这样的：
sql复制SELECT * FROM t_order WHERE user_id = 12345 ORDER BY create_time DESC LIMIT 10;
如果这条SQL里没有order_id，ShardingSphere只能向4个库的所有分表发起查询，然后汇总排序，最后返回前10条。这个逻辑本身没问题，但注意：每个分片上的LIMIT 10返回的只是该分片的前10条，归并后必须再做一次全局排序，才能得到正确结果。分片数越多，归并的数据量越大，拖慢查询。
解决办法：
- 在所有列表查询里，尽量带上user_id，我们最终把分片键配置成多列支持，并加了一个“路由提示”机制。
- 对于后台查询类接口，直接走专门的汇总库或ES，不碰在线分片表。
- 高频列表接口一定要做缓存，Redis缓存最近N页的热数据，缓存穿透时再回源数据库。
4.2 跨分片的分页：深分页问题
在分片环境下，深分页几乎无解。比如：
sql复制SELECT * FROM t_order WHERE status = 1 ORDER BY create_time DESC LIMIT 100000, 20;
在单库上这已经很慢，在分片环境下更致命。因为每个分片都要先查出100020条数据，再在内存里排序取第100001到100020条。32个分片，每个分片查100020条，内存和CPU开销瞬间爆掉。
我们最终方案是禁止业务使用深分页，改成“游标分页”或“时间范围分页”。具体做法：下一页查询时，带上上一页最后一条记录的create_time和order_id，SQL写成：
sql复制SELECT * FROM t_order
WHERE user_id = 12345
AND (create_time < ? OR (create_time = ? AND order_id < ?))
ORDER BY create_time DESC, order_id DESC
LIMIT 20;
这样每个分片只需要拿20条，归并压力也小。虽然业务方一开始不习惯，但用久了发现比深分页稳定太多。
4.3 跨库事务：从本地事务到最终一致性
分库分表后，原来一个本地事务跨了多个库，MySQL的本地事务就搞不定了。我们的订单创建逻辑涉及订单主表、订单明细表、库存扣减表，如果这三张表分布在不同的分片，事务一致性问题就出来了。
ShardingSphere提供了分布式事务方案，支持XA强一致和SEATA柔性事务。我们一开始想用XA，觉得强一致最靠谱，但压测后发现XA的性能损耗很大，尤其是跨多个分片时，2PC协议的协调开销直接让接口RT翻倍，不适合我们的高并发订单场景。
最终选择了柔性的“本地消息表+定时任务补偿”方案。核心流程是：
- 在同一个本地事务里，写订单主表和订单明细表（这两张表使用相同分片键order_id，保证在同一物理库内），并写一条“待发送消息”记录到本地消息表。
- 异步任务把消息表里的记录发送到MQ，触发后续库存扣减等操作。
- 如果消费失败，消息表会一直重试，直到成功。
这个方案的关键在于：通过设计分片键，让强关联的数据落在同一个库内，从而大部分操作可以用本地事务解决；只有真正跨库的部分才走最终一致性。经验之谈：分库分表之后，表结构设计要刻意去迎合分片键，把需要事务的关联表聚到同一个分片下，这样很多事务问题自动消失。
4.4 关联查询：能不用就不用，最好在应用层拼装
单库时代，一张订单主表join支付流水表join用户表是家常便饭。分库分表之后，这些表分布在不同的物理库中，join操作就变得非常麻烦。ShardingSphere虽然支持跨分片join，但会把join的数据全部捞到内存中做关联，数据量一大就爆炸。
我们在改造时，把绝大多数join查询改成了应用层拼装：
- 第一步，按照分片键查询订单主表，拿到订单数据。
- 第二步，根据order_id列表批量查询支付流水表。
- 第三步，在应用层用Map做关联。
这样的好处是每个查询都能精确路由，避免跨库的join数据搬运。刚开始开发同学觉得麻烦，但习惯了之后会发现，应用层拼装更灵活，也更容易做缓存。
4.5 分页排序和聚合函数：COUNT、SUM、GROUP BY的坑
聚合函数是另一个容易出问题的点。比如统计某天的订单总数，单库上直接SELECT COUNT(*) FROM t_order WHERE create_time = '2024-01-01'，而分片环境下，ShardingSphere会对每个分片执行同样的SQL，再把结果求和。如果分片键出现缺数据的情况（比如数据分布不均），COUNT的结果是对的，因为ShardingSphere会做归并，但前提是所有分片都返回了结果。如果某个分片执行失败，整个查询就失败，不会有部分结果。
GROUP BY字段如果不在分片键上，归并时还要做一遍聚合，内存压力大。我们在实际中严格控制了聚合类查询，绝大多数都改成了预先计算好的汇总表，实时性要求高的用ES或ClickHouse。
5. 上线后的稳定性保障：监控、告警与扩容预案
分库分表上线只是开始，真正的考验在之后的日常运维。这个章节聊聊我们上线后做的几件事。
5.1 慢查询监控与SQL审计
分库分表后的慢SQL，很多时候不是索引问题，而是路由问题——不是这行SQL本身慢，而是它把所有分片都打了一遍。我们在ShardingSphere中开启了sql-show日志，上线初期线上打印每一条真实执行的分片SQL，配合SKYWalking链路追踪，能非常直观地看到一条用户请求到底查了多少个分片、哪个分片最慢。
上线三个月后，我们把sql-show关闭，因为日志量太大可能影响性能，但保留了审计功能。遇到慢查询告警时，可以临时打开sql-show定位问题。
5.2 容量水位告警：不能让某一两个分片过载
分片虽然做了尽量均匀的分布，但业务数据的冷热不均还是可能存在。我们给每个物理分表都做了容量监控，通过定时任务统计每个分表的行数和大小，超过阈值就在监控平台上报警。
这里有一个容易被忽略的点：MySQL实例本身的连接数和IOPS监控比表容量更紧急。分库分表后，应用对数据库的连接数是原来的4倍，因为要同时连接4个库，连接池很容易被打满。我们把HikariCP的maximumPoolSize从原来的50调整为每个数据源30，总共120个连接，并且在压测环境下反复验证过连接池耗尽时对接口RT的影响。
5.3 扩容预案：从32分片到64分片，怎么平滑迁移
分库分表之后，最怕的就是扩容。你不可能把所有数据重新洗一遍，因为停机时间不允许。我们的思路是：分库分表的基础设计从一开始就为扩容留了空间。
以订单表为例，当前是4库*8表=32分片。如果要扩到64分片，简单做法是把每个表再拆成两个，或者新增4个库，把数据重新分布。听起来像重新迁移，但我们在设计分片键时就已经用了“可分桶”的策略。
具体来说：order_id的取模不是直接对32取模，而是先对一个大数（如1024）取模，得到一个分桶号，再把分桶号映射到具体的库表。未来扩容时，只需要修改分桶号到库表的映射关系，把部分分桶迁移到新库即可。这样数据迁移的单位从“全量数据”变成“部分分桶”，可控性强得多。
这个方法不是ShardingSphere自动支持的，需要自己在分片算法里做二次映射，代码量不大，但后续收益巨大。具体算法是：
code复制bucket = order_id % 1024
ds_index = bucket / 256
table_index = bucket % 256 / 32
扩容时，把桶区间重新分配即可，业务无感知。这种设计思路其实和一致性哈希很像，都是通过增加一层虚拟映射来降低扩容时的数据迁移量。
5.4 备份恢复策略的变化
分库分表后，备份策略也要调整。原来单库直接用mysqldump或xtrabackup做全量备份就行，现在有4个实例，备份任务要并行跑，并且要保证每个实例的备份时间点尽量一致。我们用的是xtrabackup做物理备份，每天凌晨2点对4个实例分别执行，备份文件往对象存储里传。恢复的时候，是4个实例同时恢复到同一个时间点，这个“时间点一致”其实在分片环境下很难严格做到，因为4个实例的binlog位置是独立的。我们只能做到尽量同时备份，并接受极端情况下少量数据不一致，业务上通过幂等校验来兜底。
6. 踩坑实录：那些文档里没写但非常要命的问题
最后这部分，挑几个我们实际踩过的比较典型的坑，按“问题现象->排查思路->解决方案”来讲，希望你能避开。
6.1 INLINE表达式里用了大于号、小于号导致配置解析失败
我们最初想在分片算法里加一个时间判断，比如“2024年之前的数据统一放到t_order_0”，所以写了不少create_time > '2024-01-01'这样的判断。结果ShardingSphere的INLINE表达式解析直接报错，因为YAML里的>会被当成特殊字符处理。
排查了很久才发现是YAML语法问题，>在YAML里表示折叠标量，会被解析成别的含义。解决方案很简单：把表达式放到单引号里，或者用Groovy表达式代替INLINE。
6.2 分片键是bigint，但实体类里用了Integer，导致精度丢失路由错误
这是非常隐蔽的一个问题。我们的order_id是雪花算法生成的long型整数，但某个实体字段误写成了Integer，导致值溢出变成负数。ShardingSphere拿到负数去取模，路由结果完全错乱，但数据库写入又没有报错，因为目标表还是存在的，只是数据落到了完全不对的物理分片。
这个问题排查了整整一天，最后是发现某张分表的数据量异常偏大，手动查了几条数据才发现order_id变成了负数。所以强烈建议：分布式主键字段在实体类、数据库字段、DTO里统一使用Long或String类型，并做一次全局的field type扫描。
6.3 连接池连接数翻倍后，MySQL端连接数被打满
我们刚切换分库分表后，系统运行了大概三天，突然出现大量“Too many connections”报错。原因就是我们前面提到的连接数翻倍问题。应用侧HikariCP连接池如果没调优，每个数据源默认10个连接，4个数据源就是40个连接；但如果应用实例有10个，那就400个连接，MySQL默认max_connections是151，肯定被打满。
解决方案是：重新估算连接池大小。我们每个应用实例的HikariCP配置从默认值调到每个数据源5~10，线程池并发量也做了限制。更重要的是，监控MySQL的threads_connected指标，设置90%阈值告警，防患于未然。
6.4 分布式事务的坑：SEATA模式下的undo_log表必须在每个分片库里创建
我们后来在部分场景尝试了ShardingSphere + Seata的分布式事务方案，结果遇到了一个非常典型的坑：Seata的undo_log表需要存在于每一个分片数据库里，而不是只建在主库。否则业务执行时，Seata在回滚阶段找不到undo_log，会直接报错。
这个坑之所以要单独拿出来说，是因为它特别隐蔽。一开始我们只在主库里建了undo_log，本地测试也没问题，但一上分片环境，部分事务执行时会随机出现“Table 'undo_log' doesn't exist”的报错。排查后才发现，ShardingSphere的事务会路由到不同的库，Seata的回滚日志也要跟着路由。最终我们在所有分片库都执行了一遍CREATE TABLE undo_log脚本才解决。
6.5 时区问题导致按时间范围查询数据“不翼而飞”
还遇到过一次让人抓狂的查询问题：某天早上运营反馈，前一天的订单数据查不到了。排查时发现数据库里明明有数据，但按create_time范围查询就是查不到。后来才发现是MySQL时区配置问题，数据库连接的时区是UTC，而应用代码传的是东八区的时间字符串，导致8小时的偏差，恰好跨天，所以前一天的订单落在“未来”时间上，查不出来。
这在单库时代也可能发生，但分片环境下更容易被忽略，因为每个实例的时区配置可能不一致。我们统一了所有MySQL实例和应用JVM的时区为Asia/Shanghai，并强制使用连接参数serverTimezone=Asia/Shanghai。
7. 改造完成后的效果与遗留问题
分库分表改造上线一年后，简单汇报一下前后对比：
- 订单表数据从6000万行增长到了1.5亿行，单表容量不再构成瓶颈。
- 高峰期订单写入接口的P99耗时从原来的450ms降到了120ms。
- 用户订单列表查询的P99耗时稳定在80ms以内。
- 数据库CPU使用率从峰值80%以上降到日常20%以下。
整体效果符合预期。但我也得直说，分库分表带来的附加成本不容忽视：
- 代码复杂度明显上升，所有查询必须考虑分片键是否在条件里。
- 分布式事务改成了最终一致性，业务上需要使用幂等和补偿机制，这部分对开发要求更高。
- 运维成本上升，备份、监控、扩容都要多实例操作。
- 团队内部需要定期做分片知识培训，新同学上手成本比单库时代高了不少。
如果你问我，什么情况下不建议分库分表？我会说：数据量还没到千万级，单库单表压测QPS还撑得住，业务增长没有那么激进的情况下，优先做读写分离和缓存，把单库的能力榨干再说。分库分表是最后的手段，不是第一选择。但如果数据量确实已经冲到瓶颈，而且增长趋势明确，那就趁早规划，别等到彻底卡死才动手。改造的阵痛是必然的，但越早做，数据迁移的代价越小。
最后分享一个实操上的小技巧：在分片规则设计阶段，一定要把未来可能的查询场景一次性列全，反复推演，尤其是跨分片查询、范围查询、深分页这些场景，宁可多花两周来设计，也不要上线后再推翻重来。分库分表不像普通功能可以随时重构，它一旦上线，就是长期基础设施的一部分。