十余年做后端每隔几年就会遇到一次“单库扛不住了”的时刻。这一次我们聊的还是那个绕不开的话题分库分表。前面几篇我们把拆分策略、中间件选型、路由规则这些基础都过了一遍这一篇就进到真正的实战环节——分库分表之后那些绕不开的麻烦事。全局唯一ID怎么做、分布式事务怎么落地、跨库聚合查询怎么设计、数据迁移怎么保证不丢不重这些才是把分库分表从“能跑”推向“稳”的关键。这不只是给架构师看的。只要你的业务未来有数据量增长的预期不管是刚准备入手还是已经在改造路上这篇文章都能帮你绕过几轮真实的坑。1. 整体设计与思路拆解为什么分库分表后的问题反而更复杂先给这篇文章定个调它不是一篇劝你早日分库分表的文章恰恰相反它更像一部“施工事故记录”。一旦你真正把库拆开、把表分散了很多在单库时代被你忽略掉的问题是会被无限放大的。1.1 从单库到分片的复杂度跃迁很多人只看到“把一张大表切成多张小表”误以为这是水平扩展的直接解药。实际上分库分表只是把数据按照某个键sharding key分散到多个物理节点上真正让人头疼的是分布式环境下的一致性、聚合、事务和运维。举个例子单库时代全局唯一ID直接auto_increment无缝衔接主从同步也不用管什么ID冲突。分片之后你把订单表拆成64个分片每个分片自己维护自增ID同一个订单号会出现在不同库中然后就是业务联调时的各种错乱。类似这样的问题还有很多。所以这个系列的第四篇我想把主题聚焦在“不换轮子怎么修车”上假设你已经做好分库分表的底层设施剩下的这些问题才是日常业务里真正会咬人的地方。1.2 适合第几阶段的读者如果你刚在调研分库分表建议先从前面几篇把拆分策略搞清楚再回来读这篇。因为本文默认你已经知道“为什么要分片”“分片键怎么选”“主流的中间件有哪些”。如果你已经在做技术选型或者正在改造过程中这篇内容可以说是刚需——全局ID、分布式事务、数据迁移这三件事是每一套分库分表方案都躲不开的攻坚点。我尽量把每个环节都拆到“能直接照着做”的程度包括参数位设计、同步流程、校验方案。你不需要全盘照抄但完全可以拿来做参考模板再针对自己的业务体量做裁剪。2. 核心细节解析与实操要点四个绕不开的后置问题下面按实战里的踩坑频率从高到低整理四个核心问题。每一个都附上我当时在项目里的选择逻辑和后续教训。2.1 全局唯一ID从自增主键到雪花算法先说全局唯一ID。分库分表之后最痛苦的往往是连数据库自己都给不出一个全局唯一的主键了。主流的方案有两个方向号段模式代表实现是美团Leaf、滴滴Tinyid。核心思想是一张号段表记录当前分配的最大ID每次从号段表取一批ID缓存在内存里发完再去取。这种方案ID是纯数字趋势递增对索引非常友好缺点是引入了额外数据库依赖。一旦号段表所在数据库抖动全局发号器就会受影响所以生产环境我一般会给它加一个前置的读缓存。雪花算法Snowflake标准雪花是64位1位符号位 41位毫秒时间戳 10位机器ID 12位自增序列。41位时间戳支持69年10位机器ID最多1024台机器12位序列在每毫秒内可以生成4096个ID。雪花算法最大的坑是时钟回拨。机器NTP同步导致时间倒退同一毫秒内生成的ID可能重复。我遇到过的解法是把10位机器ID拆成“5位机房号5位服务号”一旦检测到时钟回拨直接抛异常等待代码里给一个容忍范围。不过如果你的机器时钟漂移比较多建议直接上号段模式因为它不依赖时间纯粹依赖数据库和内存稳定性更可控。2.2 分布式事务强一致在分布式世界里是奢侈品在单库时代一个事务里随意更新订单表和库存表脏数据一样能回滚。分库分表后这个事务就变成了跨多个库的分布式事务。很多人上来就问“是不是两阶段提交2PC就能解决”理论上是的但在高并发、弱网环境下2PC有很多实际问题协调者宕机、参与者挂起、网络分片、数据锁释放不了。一旦出现这些问题你会发现业务被“卡死”的比例比不拆库前还高。我踩过坑之后的建议分两档核心支付、账户类场景尽量通过“本地消息表 消息队列”实现最终一致性。具体做法是把“写业务表”和“写消息表”放在同一个本地事务里然后用一个异步任务去投递消息、驱动后续服务完成更新。这个方案看着糙但它是所有方案里能够最大限度保证“不丢消息”的。营销、弱一致性场景直接上事务消息或SAGA。例如发优惠券、更新积分和记录用户浏览行为完全没必要追求数据强一致最终一致就足够了。需要提醒的是不要迷信“分布式事务中间件可以把多个本地事务打包成一个整体”这类中间件往往需要业务侵入代价很高。能用业务设计解决的比如先扣款后扣库存把并发冲突转移到单个事务内很多时候比引入重中间件划算得多。2.3 跨库查询没有了join只有组合查询思维这是很多从Oracle/MySQL单库业务转过来的开发者的思维盲区。以前你写一条SQL带三个join把订单表、用户表、商品表一次性查出来。分库之后订单在库1用户在库2商品在库3数据库层面的join就彻底无了只能靠应用层去组装。常见的降级方案有这么几种冗余字段订单表直接冗余下单时的用户名、商品快照、价格。查询订单列表时直接查分片表不需要再关联用户和商品。牺牲一点存储换来查询路径大幅缩短。这套方案最简单也适用90%以上的列表页场景。应用层聚合先把订单查出来拿着user_id列表去用户分片里批量查再用Map拼装。关键点是要注意批量查询的条数单次in列表建议不超过500个否则数据库性能断崖式下跌。汇总表 / 宽表异步从各分片汇总到一张汇总大表专门支撑报表、统计类查询。这个方案适合“读多写少且对一致性要求不高”的场景。搜索引擎如果查询维度特别多组合条件特别复杂比如商品搜索、订单检索建议直接引入ES或数据仓库用binlog同步数据。库只负责事务性读写查询和统计交给搜索引擎。这里没有最好只有最合适。我的经验是优先冗余字段其次应用层聚合最后才是重引搜索引擎。流程越短越好维护。2.4 数据倾斜split后的大头还是在一个节点上分库分表解决的是“表数据量太大”的问题但它没有自动解决“热点数据集中”的问题。典型的失败案例是按业务ID取模分库分表结果80%的流量都集中在某几个ID上形成了一个大热Key。这个热Key所在的库节点负载高得吓人其他节点却很闲。还有一个很常见的坑一张表在初期数据量不大时你选了取模分4个库等数据量翻倍时想再扩到8个库原来分散好的数据几乎全部需要迁移。这就是为什么现在新的项目我都会优先考虑一致性哈希。一致性哈希的优点是扩容时只影响邻近节点迁移的数据量小很多。但它不是银弹哈希环加虚拟节点后虽然降低了分布不均的概率但定位和路由复杂度也上升了。所以在实际选型的时候我的建议是业务主键有明显前缀并且你可以预估未来规模直接用范围分片天然利于扩容。前缀不可控、热点不可测取模容易出现严重倾斜那就用一致性哈希并且设置足够多的虚拟节点。记住一个原则拆分键的最终目的是“把流量平均摊开”不是让一张表变小就行。3. 实操过程与核心环节实现一次单库升级分库分表的完整路径这部分我把之前实际操盘过的一个订单场景项目整理成完整流程从容量评估到流量切换按步骤走。数据规模可以理解为单表千万级、QPS到几千、峰值扛不住的典型场景。3.1 容量评估与拆分键选择动手之前先算清楚账。当时的业务表是“用户订单表”大约1500万行还能查但已经明显慢。我们按三年后订单量达到1亿条、单行约600字节估算全表大约60GB单机MySQL要扛这么大的表和这么高的查询并发已经不现实。拆分键的选择标准很简单高频查询能否直接带上这个键。订单表筛选条件大部分是user_id所以我们选择按user_id做分片规则为user_id % 16拆成16个分片分别落在4个物理实例上。这里有个容易被忽略的细节分片粒度。拆成16个还是64个不是拍脑袋。我在实践里会用下面这个公式做粗估算假设单库单表建议容量上限为5000万行保守一点的可以折半到2000万行。期望3年后全表1.2亿行那么分片数量至少是1.2亿 / 2000万 6向上取整到8或16为佳留出余量。同时要考虑单实例连接数例如一个实例最多能承受2000个并发连接拆完16个表到4个实例每个实例平均4张物理分表连接数压力要分配均匀。预估完分片数再定路由规则。我实操中不直接在业务代码里写% 16而是通过中间件的配置在测试环境验证路由避免上线后才发现分片键选择失误。3.2 数据迁移与双写方案存量数据已经全在原来的单表里不能停机太久那就得走双写。双写的基本思路是代码层写老库的同时异步或同步写新库。注意写新库的失败不能影响主链路所以常通过消息队列异步写。先做全量数据迁移把老库的历史数据搬到新库。迁移期间对老库的增量数据持续通过MQ同步到新库。开启数据校验任务定时比对老库和新库的数据量、关键字段、校验值。校验通过后把读写流量逐步切到新库保留老库只读作为回滚。具体拆分下来双写落地的关键代码我建议这样设计// 示例同步老库 异步双写新库 public void createOrder(Order order) { // 1. 老库事务保证原有系统主流程稳定 Long id orderDao.insert(order); // 2. 异步双写失败不阻塞主流程 mqSender.send(order-sharding-sync, order); }消息队列消费者里做新库写入并通过本地重试死信队列保证最终写入成功。这个做法的问题是极端情况下存在消息丢失的风险但对非资金类的数据业务容忍度是够的。资金类数据我建议直接同步双写并且以新库为主库老库作为校验不要异步。此外全量迁移我用过两个方案简单场景直接用中间件自带的迁移工具复杂场景写脚本按主键范围分页扫老库数据一条条插入到新库。后者慢一些但可控性更强。整个全量过程要特别小心批量插入不要一次插太多行我当时一个批次控制在500条左右避免目标数据库写放大或锁竞争。3.3 数据校验与流量切换这里必须说一个听起来简单、执行起来非常繁琐的环节数据校验。我做过的最高效方式是“总量先行、抽样校验、CRC入库”。总量先行分别统计老库和新库的行数先在数量级上对得上号。抽样校验对于资金、状态类字段按月抽样用SUM(amount)、MAX(update_time)做聚合比对。CRC校验对每条记录的多个字段做拼接后算MD5或CRC32然后在新老库分别计算整体哈希值最后比对这些哈希值是否等同。如果等同基本可以认为这两个库的数据是一致的。这个校验动作在老库仍然接收线上读写的情况下频繁跑存储压力不小所以我把校验高峰期放在业务低峰期。流量切换要“灰度”。线上切流量时我已经提前在老库上保留了一套只读账号一旦新库出现问题代码配置中心的开关可以直接把读写切回老库而不是频繁发布版本。整个灰度过程大概分了三批先是内部账号全量切新库再是10%的用户切新库观察一段时间后再全量切换。这样做最大的好处是可以随时止损。4. 常见问题与排查技巧实录这个章节的内容是在多个项目里沉淀下来的问题清单。每条我都尽量还原当时的问题现象和排查路径方便你直接对号入座。4.1 路由结果不一致导致的“找不到数据”现象同一个userId在测试环境能查到数据预发环境却查不到或者明明数据在库里却查不出来。排查大概率是路由规则不一致。比如测试环境用的分片配置是user_id % 16预发环境被某个配置覆盖后变成了hash(user_id) % 16。这一条很容易被忽略尤其是在中间件配置中心管理的情况下。我的建议是把路由配置放到独立的配置项中并把“路由键”的值打印到请求日志里。调试时直接看日志里路由出来的分片编号再和数据库实际数据所在的分片比对就能迅速定位问题。另外不要使用隐式路由也就是不让代码自己去猜分片键。4.2 分布式事务回滚失败后的脏数据现象一个跨库的事务业务代码先更新了订单库再更新库存库第二个库更新超时导致代码捕获异常并尝试回滚。结果订单库回滚成功库存库回滚失败数据就不一致了。排查方式通常不是靠肉眼对数据而是比对两边的日志。我会在跨库事务的每个写操作后都打印“写入完成影响行数”如果哪一个库没有这条日志基本就锁定在它身上。这里真正要改的其实是设计不要把两件没有强事务关联的事硬塞进一个事务。如果迫不得已优先用SAGA做补偿并在补偿逻辑里实现幂等。比如生成一个交易流水号所有补偿事务和主事务都按这个流水号做去重防止重复执行造成二次脏数据。4.3 迁移后数据不一致现象全量迁移完成后总量对得上抽样也整体一致但业务上仍有零星几条数据状态是旧的比如一张订单的状态在订单详情页显示为“已支付”在订单列表页却显示为“未支付”。排查下来最常见的两个原因全量迁移期间产生的增量数据没有完整同步因为某些消息在写MQ时没有设置分区键导致同一个订单的多个消息被乱序消费。新老库同时写入了相同主键但内容不同的数据校验工具只比对了主键存在性没比对更新时间。针对第一点我在消费者里加了一个“版本号更新时间”的保护机制只有当消息里的数据版本大于当前库里的版本时才允许覆盖。这个写法虽然简单但救了很多次命。针对第二点强烈建议校验任务的比对字段一定要包含主键、更新时间、关键业务字段不要只对比记录数。4.4 中间件连接数被打满现象分库分表之后应用连接池的占用率反而比单库时代高很多最终导致数据库报“Too many connections”。原因非常典型一条简单的SQL在某中间件里会按照分片规则拆成16条子SQL每个分片都建立一次连接。如果你的连接池总共30个并发一高瞬间占满。排查时看中间件监控里的分片执行耗时和连接数统计就能定位。解决的思路也很明确提升连接池上限但也要小心拖垮数据库。尽量在一条SQL里带上分片键这样中间件能精准路由到单分片而不是全分片广播。对于没有分片键的查询做限流或走汇总库/ES不要让它穿透到所有分片。4.5 拆键选择失误后回天乏术的痛这是我最后想说的一个坑也是最有价值的。有的团队在订单表上选了order_id作为分片键但所有业务查询都是通过user_id去查。前者虽然让订单表分布均匀却让所有“查某人的所有订单”成为全分片广播查询。这种拆键一旦上线后续要换路由规则数据要重新按其他键做二次迁移工作量极其可怕。所以在敲定拆分键之前一定要做一件事把系统里的所有SQL都拉出来按照查询条件的命中频率排个序。选那个命中频率最高、且后续增量也会高频使用的字段作为分片键。这一步省不掉。5. 更进一步分库分表之后的长期规划别以为切完流、校验完数据就是终点。分库分表是一个持续演进的过程有些事在方案设计之初就埋下了伏笔。这里再把视角往前拉一点。5.1 从分库分表到读写分离的混合架构分库分表和读写分离并不是互斥的。实际项目里很多分片节点还会挂一个只读副本把统计、报表、后台搜索类请求导流到只读从库减轻主库压力。这样做的代价是“数据延迟”所以从库上的查询只能用在可容忍延迟的场景比如排行榜、日终报表而不是实时的资金流水。如果你要让从库服务所有查询就得在中间件层加“主从延迟检测”一旦超过阈值自动绕开从库否则会出现查询数据比主库旧的问题。5.2 分片扩容与重分片的预案不管选什么路由算法总有一天数据量会超过当前分片规模的预期。既然做这个系统就不能不提前规划扩容方式。常见有两种思路提前过度分片比如当前只需要4个分片直接拆成64个分片以后扩容时只做数据迁移不用改路由规则。代价是前期建了很多空表运维略繁琐。按范围分片比如按用户ID区间划分扩容时一个区间拆成两个子区间压力只涉及局部数据迁移。我倾向于按范围分片加定期重评估因为这个方案更容易自动化。不过范围分片会导致热点区间问题因此运维上需要加一层“数据总量监控”一旦某个区间提前达到阈值及时介入调整或二次拆分。5.3 组织协同与代码规范分库分表不只是一个技术课题更是团队协作的课题。我这边的经验是从改造一开始就要求在DAO层的所有方法上都标注“分片键字段名”并且代码评审时重点检查有没有出现无分片键的查询。如果你用的是sharding中间件它通常会提供一个“强制路由”或“SQL审计”能力建议打开把没有分片键的SQL全部拦截并打印警告。默认拦截白名单放行而不是默认放行然后靠人肉排查。这一点真的非常重要。等线上跑上三个月后发现大量慢SQL都在扫全分片再想去纠正就不是加个键那么简单了。在收尾前把个人的三个习惯再分享一次分库分表这种东西方案很多文档很多教程也很多但真正让项目稳定的往往不是某个炫技的中间件而是一些不起眼的习惯。第一个习惯所有跟分片相关的操作都打日志。不要嫌日志丑、保存量大排查问题时这些日志就是你唯一的线索。第二个习惯每次上线大版本前把“新老双写 数据校验”的定时任务手动跑一遍哪怕只是抽样。机器是机械的我的经验是前面跑十次都没问题真正要命的问题往往在第11次才会出现。第三个习惯永远给自己留一条回滚的路。不管是开关切换、只读账号还是灰度发布只要还能快速回到旧架构胆子就可以大一点但永远别在没有回退方案的情况下全量切流量。分库分表没有“一劳永逸”它更像是在业务成长过程中被迫做出的选择。如果你正在这个阶段的十字路口希望这篇“第四篇”能帮你在思路上更清晰一点、少踩几个已经被人踩平了的坑。