分库分表实战：路由规则、跨节点查询与平滑扩容的坑与解法

近两年做中台和数据类的项目十有八九会遇到单表数据量撑不住的情况。很多人一听到分库分表第一反应就是“不就是把表拆开吗”但真正动手做的时候才发现拆只是万里长征第一步。我的系列文章前面已经聊过拆分策略、中间件选型和容量预估这篇“分库分表四”就专门挑那些真正会让项目卡壳的地方来聊——路由规则怎么设计才不踩坑、跨节点查询怎么处理排序分页聚合、分布式ID到底选哪种方案、以及扩容和迁移数据时那些让人头秃的问题。这篇文章适合正在做技术方案设计、或者已经上了分库分表但遇到疑难杂症的开发者。我会用实际项目中真实遇过的案例来讲包括一些只有踩过坑才会记住的细节。内容比较长但每段都是干货可以直接拿去参考。1. 路由规则设计决定了你的SQL该去哪张表分库分表之后所有的查询都必须先回答一个问题这条SQL应该路由到哪个节点、哪张表这个过程叫路由计算。路由规则设计得好不好直接决定了系统是高效稳定还是到处埋雷。1.1 单键路由最常用但别忽略取值分布最常见的路由规则就是单字段取模比如order_id % 16算出分表序号。这种方案实现简单性能也好但有一个非常隐蔽的问题取模字段的值分布必须足够均匀。我在一个订单系统里就吃过亏。当时用user_id % 32分表以为用户访问是均匀分布的结果运营搞了一个大促活动某个头部主播带货产生了海量订单这些订单集中在少数几个用户身上导致某几张分表的数据量是平均水平的20倍以上磁盘占用、写入锁竞争、慢查询全都冒出来了。所以设计路由字段时不要只看“能不能唯一标识一条记录”还要看“这个字段的取值会不会出现长尾效应”。如果业务上明显存在热点用户、热点商家就要提前考虑加盐处理或者干脆把热点账号单独扩容、单独路由不要让所有流量都挤在同一个取模分片上。1.2 多键路由与冗余存储的思路很多业务查询不只是按一个维度比如订单系统既要查“某个用户的订单列表”也要查“某个商家收到的订单列表”。如果只按user_id分表按商家维度查询时就必须全库扫描这在数据量大了以后完全不可接受。业界比较常见的解法是冗余存储生成订单时写两份一份按user_id分表做主数据一份按merchant_id分表做查询索引。听起来浪费存储但在海量数据背景下存储成本往往比查询性能便宜得多。还有一种折中方案是用中间表记录映射关系比如维护一张“商家-订单”的宽表只存必要字段查询时先查映射表再回源。这样写逻辑复杂一些但能减少冗余带来的数据一致性问题。到底选哪种取决于你的读多还是写多、以及数据一致性要求有多高。1.3 广播表与全局表的设计细节有些表数据量不大但几乎每条SQL都要关联比如商品类目表、配置表、行政区划表。这种表不应该分片而应该在每个分片上保留全量数据中间件会自动把对这些表的操作广播到所有分片。但广播表有一个需要重点注意的问题更新频率不能高。因为每次更新都要同步到所有分片中间的延迟可能导致部分节点数据不一致。我们的实践经验是配置类数据先放缓存或者CDN定时同步到分片表真正需要强一致的极少别为了省事去高频更新广播表。另外设计路由字段时如果用了复合分片键比如同时用user_id和region_id就要明确主分片键和辅助分片键的优先级。中间件计算路由时通常只认第一个分片键后面的是用于过滤条件不能参与路由定位。很多新手在这个地方想当然以为多传几个条件就能自动路由对结果查出来的数据是空的排查半天才发现是路由键优先级的问题。2. 跨节点查询的三座大山排序、分页、聚合分库分表后原来单库单表上很简单的 SQL 在分布式环境下会变得极其难处理。这里我挑最常见的三个场景展开讲每个都是实战中一定会遇到的。2.1 全局排序你以为排完了其实每个分片只“部分有序”ORDER BY在单表上是原子操作跨分片之后就变成了一个典型的多路归并问题。中间件的做法是先把 SQL 下发到每个分片执行每个分片各自排序返回中间件再对多个有序结果集做归并排序才能保证全局有序。这里必须注意偏移量的问题。比如你想查全局第100到120条如果直接LIMIT 100, 20下发每个分片返回的是各自第100到120条不是全局的。正确的做法是把偏移量加在每一条下发的SQL上也就是分片执行LIMIT 120中间件再做归并取前120条最后截取第100到120条。这个操作极其消耗内存和带宽。数据量小还能忍数据量大的时候比如查第10000页每个分片都要拉一万条记录上来系统迟早被拖垮。所以分库分表之后深度分页就是一个无解的性能陷阱唯一的出路是业务层面改掉——用游标分页也就是把“翻到第N页”改成“按上次最大的ID往后查”。2.2 聚合函数COUNT、SUM、AVG 都要先搬再算COUNT(*)在分片环境下不能直接把所有分片的结果加起来因为不同分片可能返回不同数量的记录但中间件通常会对下发的 SQL 做改写把COUNT(*)变成COUNT(*) AS cnt再对结果相加这没问题。但AVG就有问题了平均值不能直接对各分片的均值再取平均必须先取各分片的SUM和COUNT再统一运算。举个例子分片A的平均值是100分片B的平均值是200你直接(100200)/2150是错的。正确计算方式是(sumAsumB)/(countAcountB)。很多中间件在处理聚合查询时会有自动改写能力但如果你是在业务代码里自己拼接SQL这个坑很容易踩到。还有GROUP BY配合ORDER BY的场景也是先聚合再排序这个顺序搞错了结果就完全不对。我的建议是分库分表之后能不做聚合尽量不在SQL层做把数据拉到应用内存里做计算。为了支撑这个方案建议在分片键之外设计一套“汇总表”定时把当天/当周的数据聚合好查询直接走汇总表性能和准确性都有保障。2.3 连接查询JOIN要重构而不是硬撑单库时代写惯了JOIN分库分表后真的要改变习惯了。分片键不同两张表的数据可能落在不同的物理库上JOIN 操作就需要中间件从多个分片拉数据到内存里做关联这就是跨库 JOIN性能非常差。我的经验是优先做字段冗余把关联查询改为单表查询。比如订单明细需要商家名称那就把商家名称冗余到订单表中查询时直接取根本不用 JOIN。如果数据量允许还可以用两次查询代替 JOIN——先查出主表数据再根据关联ID批量查附表在应用层组装。这个方式在数据量可控的情况下性能和灵活度都很好。3. 分布式ID方案选型一张表看懂各自优缺点分库分表之后自增主键就彻底不能用了。因为多个分片各自自增会生成大量重复ID。业界常见的几种分布式ID方案我直接用表格对比方便选型。方案核心思路优点缺点适用场景UUID全局唯一字符串实现简单本地生成无网络开销过长、无序严重影响索引性能非核心表、日志类数据数据库号段从库中批量取ID段本地生成性能好ID趋势递增依赖数据库号段丢失会跳号中小规模业务Redis自增利用INCR/INCRBY生成性能高实现简单Redis故障影响全局需做高可用对ID连续性要求不高的场景雪花算法时间戳机器ID序号高性能无中心化依赖趋势递增依赖时钟时钟回拨会重复ID大规模分布式系统的主流选择我在项目中最常用的是雪花算法但使用时有几个细节必须注意。雪花算法生成的ID是64位长整型标准构成是1位符号位 41位毫秒时间戳 10位机器ID 12位序列号。理论上单机每毫秒可以生成4096个ID。但如果你用默认配置没指定机器ID在多实例部署时很容易因为机器ID冲突产生重复ID。建议在部署脚本里明确指定每个实例的workId从配置中心动态下发不要依赖代码内置。时钟回拨是另一个隐患。系统时间被NTP校准或者运维手动调整可能导致当前时间小于上次生成ID的时间戳从而生成重复ID。解决方法是记录上次生成ID的毫秒时间戳回拨时用等待或者使用备用位补偿。极端情况下比如回拨超过几秒宁可抛异常也不要硬生成。4. 平滑扩容与数据迁移把服务停了是下下策分库分表一旦上线扩容就变成了无法回避的问题。最粗暴的做法是停服把数据全量导出再按新规则重新分布再启服务。小项目可以接受但核心业务停机几小时业务方肯定会炸。所以现在主流都追求平滑扩容也就是不停服完成数据迁移和路由切换。4.1 主流扩容方案双写 影子表 灰度切换我的标准操作流程是这么做先在数据库里建好新分片结构和影子表shadow table和正式表结构一致但命名不同比如order_info_new。修改应用代码写入操作同时写老表和新表新表的写入逻辑使用新分片规则。开启双写后写一段历史数据迁移程序把老表的数据按新规则导入新表。迁移过程中持续做数据比对核对老表和新表的数据量、关键字段的聚合值是否一致。比对通过后把读流量按比例灰度切到新表比如先切5%、再切20%、50%观察监控指标。全部流量都切换成功后停掉双写下线老表。这个过程听起来不复杂但有一个大坑双写期间的数据一致性。老表和新表的写入不是原子的如果新表写入失败老表写成功就会造成两边数据不一致。我的经验是双写失败时先把差异记录到日志表后续定时任务补齐不要阻塞主流程。4.2 迁移工具选型与常见坑数据迁移工具选择很多有几个常见的坑要提醒自己写导出导入脚本时不要一次性把所有数据读进内存要用游标分批次处理否则OOM等着你。迁移过程中源表有持续写入导出的数据是快照快照之后的新数据要靠双写补。所以先开双写再跑迁移顺序不能反。主键冲突是迁移中最常见的错误。用自增ID的老表迁移到新表时新表的ID顺序可能会变务必在迁移脚本中显式指定主键不要依赖数据库自增。每个批次迁移完要校验。最简单的校验方式是比对COUNT(*)和SUM(order_amount)复杂一点的可以用抽样核对几条记录的所有字段。4.3 停机迁移的“最后防线”方案即便有了平滑扩容有时候也不得不面对停机迁移的现实——比如老系统架构过于老旧改造成本太高或者硬件故障必须紧急迁移。这种情况下哪怕要停机也要控制在分钟级别而不是小时级别。我的做法是把迁移分为两个阶段第一阶段在业务低峰期进行全量数据复制这个过程业务不暂停第二阶段在正式切换窗口内只需要复制第一阶段结束后产生的增量数据增量复制几个G以内的数据通常在几十秒内能完成。复制完后做一次简要校验直接切换连接串整个过程尽量控制在5分钟以内。5. 分库分表后的读写分离与连接管理数据量大了读写比通常也很悬殊。分库分表的同时再叠加读写分离可以让总体的吞吐量上一个台阶。但中间件的配置、应用侧连接池的管理策略都要跟着调整里面有不少容易被忽略的细节。5.1 读写分离的延迟问题怎么解决主从复制的延迟在分库分表环境会被放大。原来单库单表架构下延迟通常只有几十毫秒但在大规模数据写入时从库延迟可能飙到几秒甚至更久。用户写下一个订单马上刷新列表结果看不到刚下的单就会投诉。应对延迟的方案有两个常用思路关键业务走强一致读。比如订单详情页直接走主库普通列表页走从库。设置“写后读”标记。用户刚提交完写操作短时间内强制该用户的请求走主库超过阈值后再切回从库。实现上我通常用一个ThreadLocal存当前请求是否需要走主库访问从库的连接池时判断一下路由规则。这个方案简单可靠能覆盖绝大多数业务场景。5.2 连接池参数要重调分库分表中间件通常会持有大量后端连接连接池的配置策略和单库单表时代完全不一样。核心调整点有两个第二个是连接的最大空闲时间不要设得太短否则高峰时频繁建连数据库端会有大量 TIME_WAIT照样拖垮性能第二个是每个分片的连接数上限不要因为总的连接数看着大就掉以轻心数据库端通常存在连接数上限无脑扩大连接池反而触发数据库的too many connections错误。我常用的经验值是每个分片的核心业务连接池上限设为CPU核数的2倍到4倍非核心业务减半并且设置连接空闲回收时间大于数据库的 wait_timeout避免空闲连接被服务端强杀后客户端还在使用。6. 配置与监控没有这层出问题的时候只能抓瞎分库分表系统一旦线上运行故障排查的难度远高于单库。没有完善的配置管理和监控体系出了问题就像没有仪表盘的飞机全靠猜。6.1 路由配置要能够动态调整分库分表中间件的路由规则应该放在配置中心不在代码里硬编码。配置中心的好处是可以动态调整分片规则、切换读写比例、开启或关闭某些表的分片而不需要重新发布应用。我印象特别深的一次事故因为要临时调整一个分表的取模位数开发直接改了代码发版。结果配置和代码版本没对齐一部分请求走到了旧规则一部分走到了新规则正好赶上业务高峰瞬间出现大量查询不到数据的告警。后来我们规定所有分片规则的变更必须走配置中心发布流程里自动检测配置变更并要求关联文档同步更新。6.2 监控指标要按分片粒度收集监控不能只看全局指标必须细化到分片级别。我建议重点监控这些指标每个分片的 QPS、慢查询数、连接数。每个分片的磁盘使用量和增长趋势。每张分表的最大数据量和最小数据量及时发现数据倾斜。中间件的路由耗时、归并耗时、内存占用。大促之前做容量评估这些指标是唯一的依据。我记得有一次通过磁盘增长趋势发现某分片的数据量会在两个月后达到警戒线提前添加了新分片并做了数据迁移避开了后续的磁盘满事故。6.3 故障演练是最后一层保险无论是中间件、网络还是数据库都可能出故障。平时不演练故障真的来了会手忙脚乱。我会定期做一次故障演练比如手动停掉一个分片看看应用会不会整体不可用监控能不能及时告警流量能不能自动摘除故障节点。很多团队不敢做演练怕影响线上。我的建议是先在灰度环境演练把混沌工程工具配合进来自动化执行演练结束后出报告。这个投入是值得的因为分库分表环境的故障波及面太大了一次没有预案的故障可能造成全站瘫痪。7. 前面四篇的经验总结记住那些让我后悔没早点知道的细节写到这里结合前面三篇内容我想再把几个特别容易忽略的经验集中说一下可以当成查漏补缺的清单。分片键一旦定下来就别轻易改。更换分片键意味着数据重分布、应用改造、查询逻辑全部重写成本极高。所以设计阶段一定要充分调研业务查询模式选一个“几乎不会变”的维度。能不拆就不拆拆了就要对业务做减法。分库分表确实能解决容量和性能问题但它带来的复杂度是指数级上升的。只有在容量评估后确认单库单表撑不住的时候才动手。写操作尽量控制在单分片上。跨分片事务是分库分表里最影响性能的功能之一能用最终一致性解决的不要硬上强一致。永远给未来留扩容空间。最初把表分成64张比起分成16张在未来的扩容成本上差别很大前期稍微多分几张后面能省很多事。读写比例和热点字段要常态化观察。没有一成不变的业务之前设计时预估的比例很可能半年后就变了。回到主题分库分表四这一篇聊的主要是把系统真正落地时绕不开的工程问题。很多人看分库分表的技术选型和原理都头头是道真正上线后才发现细节里的魔鬼。路由规则、跨节点查询、分布式ID、平滑扩容、监控运维每一个环节单独拿出来都够写一篇长文但所有的努力归根结底都是为了同一个目标——让系统在海量数据下还能保持稳定、可控、可扩展。这组系列文章写到第四篇核心的思路已经基本讲全了。后面如果有机会我可能还会专门写一篇关于“分库分表中间件源码分析”的内容那是另一个层次的故事了。