分库分表架构与框架选型：从分片键设计到数据迁移实战

凌晨两点，告警群里突然刷出一条主库活跃连接数超过阈值的消息。我当时的第一个反应是检查慢SQL，但等到登上数据库看一眼，才发现问题比想象中严重得多：一张订单表已经接近三千万行，单库的写入TPS早就逼近了物理上限，所有慢查询都在这一张表上堆积，连接数被拖到打满。那天之后，我对"分库分表"这件事的态度彻底变了——它不是一个可以临时救火的优化手段，而是一个必须在技术选型阶段就想清楚、在架构层面预留好边界的长期决策。

这篇内容我打算围绕"分库分表架构与框架"这条主线，把实际项目中真正绕不开的部分讲透：什么时候应该动手拆、分片键和路由怎么设计才不会给自己挖坑、主流的框架形态之间该怎么选、数据迁移怎么平稳落地，以及上线之后那些教科书里不写的分布式难题和线上坑。不管你是正在评估要不要分库分表的负责人，还是被安排去做方案调研、框架接入的一线开发，这篇文章提供的是可以直接照着判断和执行的思路。

1. 分库分表的边界：什么时候该动手，什么时候该克制

很多人对分库分表的态度是两个极端：要么把"单表数据量过大"直接等同于"必须分库分表"，要么觉得引入中间件之后一切问题就自动消失。这两种想法都会出问题。先说结论：分库分表解决的是单库单表的资源瓶颈，而不是普通的慢查询性能问题。如果把两者的边界搞混，你会在引入分布式复杂度之后，发现自己面对的困难比原来多了一倍。

1.1 判断拆分的真实信号

我判断一个业务是否真的需要分库分表，通常看三个信号，不是看网上的约定俗成，而是看系统的实际状态。

第一个信号是写入吞吐的物理瓶颈。单机MySQL的写入能力是有上限的，这个上限来自磁盘IO、日志落盘、刷脏页的速率等多个因素。当业务峰值写入把主库的IO利用率持续推到80%以上，并且通过加硬件、优化写入模型都无法缓解时，说明单库的写入天花板已经锁死了你的业务增长空间。这个时候分库，本质上是在水平扩展写入能力。

第二个信号是单表数据量级带来的访问退化。注意，这里说的是"退化"，不是"变慢"。当一张表的数据量从百万级涨到数千万甚至上亿，InnoDB的B+树索引层数会加深，但单纯靠索引仍然能维持不错的查询性能。真正的退化出现在两个场景：一是写热点集中，行锁竞争激烈，比如一条业务主数据被高频更新；二是范围查询、批量扫描类操作与在线业务共存，锁等待和IO争抢互相放大。如果通过冷热分离、归档旧数据、优化索引这些手段都无法把数据量压回合理区间，那么拆分才是下一步该考虑的事。

第三个信号是连接数的结构性打满。这一点很容易被忽视。单库可用的连接数是有限的，应用侧的连接池即便做了合理的上限配置，当业务模块越来越多、每个模块都直连同一个主库时，连接数冲突只是时间问题。这个问题不是数据量大导致的，而是"太多服务共享同一个库"导致的。此时按业务域分库的意义，比单纯按数据量分表更重要。

1.2 哪些场景其实不用拆

我在实际评估过的一些项目里，有相当一部分咨询分库分表的业务，最后都被我用更简单的方式解决了。

慢查询问题，优先排查索引设计，而不是拆表。我遇到过查询条件里对索引列做了函数处理、或字段类型不一致导致索引失效，这类问题通过改写SQL就能解决，跟数据量没有关系。还有一种情况是查询结果集过大，SELECT出来的列里有大字段，网络传输和临时排序把资源耗尽，这种是查询姿势的问题。

读多写少的场景，优先考虑缓存分层，而不是分库。比如商品详情、配置类数据、用户基础资料，这类数据的读量很大但变更频率低，把热数据放在缓存里就可以扛住大部分流量，数据库的压力根本没到需要拆的程度。

冷热混存的场景，优先做归档，而不是平分数据。很多表的问题不在总体数据量，而在于"一张表同时承载了高频在线访问的近期数据和几乎无人访问的历史数据"。我曾经处理过一个订单相关的业务，三年数据两千多万行，看起来很多，但真正被在线业务频繁访问的只有最近三个月的几十万行。把历史数据归档到独立的归档库或者分区表里，主表性能立刻恢复，完全不需要做分库分表。

单表几千万行但访问模式非常集中、且每条查询都走得通索引的读多写少场景，也不建议急着拆。这时候拆分的收益不明显，反而要付出跨库查询和分布式事务的代价。

1.3 拆分之前必须算清的代价账

上线分库分表之前，我习惯在方案文档里明确列一张代价清单，让团队所有人对这件事有共识。拆分的收益很清晰：水平扩展写入能力、降低单表数据量、分散连接压力。但代价往往被低估：

• 跨库Join基本不能用了，原本一条SQL能完成的关联查询，要改成多次查询或者引入宽表冗余。
• 分布式事务成了绕不开的话题，跨分片的数据一致性需要额外机制保证。
• 全局主键不能再依赖数据库自增，需要引入雪花算法、号段模式或者专门的主键服务。
• 数据迁移是个大工程，存量数据要平滑搬过去，增量也要对得上。
• 排障链路变长，一条慢SQL要从应用、中间件、具体分片三层去定位。

把这些代价和收益放在一起看，你就能判断一个业务是否真的到了非拆不可的地步。下一步要考虑的问题，就是如果确定要拆，分片键和路由方案怎么设计才能不给自己埋雷。

2. 路由与分片：分库分表的核心机制和常见误区

分库分表架构里，分片规则是整个系统的地基。地基打歪了，后面所有框架选型、SQL改造都白做。这一章我重点讲分片键的选择逻辑、最常见的取模路由原理，以及大部分人第一次设计时会踩的认知误区。

2.1 分片键：一次选错，后面全是补丁

分片键，也叫分库分表字段，是决定一条数据应该落到哪个分片的核心依据。选分片键这件事，我见过太多拍脑袋定下来的案例，等到上线半年后才发现问题，改分片键的成本几乎等于重做一次迁移。

分片键必须同时满足三个条件，少一个都会出问题。

第一是值域要均匀。只有数据沿着分片键均匀散开，各个分片的数据量和访问压力才能均衡。比如按订单ID分片，订单ID本身是高频随机生成的，分布天然均匀，这是好分片键。按地区分片就非常危险，因为有的地区订单量是其他地区的几十倍，按地区打散之后，某些分片很快会被打爆。

第二是查询亲和性要高。所谓亲和性，就是业务里高频的查询条件是否都带这个字段。这一点经常和"均匀性"打架。最典型的例子是订单场景：如果你按订单ID分片，那么按订单详情查询确实高效，但如果用户端的核心页面是按"我的订单列表"来访问的，查询条件通常是user_id，这样每查一次就要把所有分片都扫一遍，路由等于失效。正确的做法，是想清楚当前业务里最核心、最高频的归属维度是什么。用户维度的业务优先按user_id分片，让同一个用户的数据尽量落在同一个分片上；商家维度的业务就按商家ID分片。

第三是字段要相对稳定。换句话说，分片键的值在数据生命周期内不应该被修改。你想想，如果一条数据被update操作改了分片键的值，它理论上应该移动到另一个分片，但移动数据这件事在一个对外服务的系统里是非常难做的。所以建议选那些从创建到归档都不会变化的属性，比如订单号、用户ID，而不是手机号、地理位置这类可能变的属性。

2.2 取模路由的原理与局限

最常见的路由算法是哈希取模，用分片键的哈希值对分片数量取模，得到分片序号。这里的"哈希"不一定用复杂的哈希函数，很多时候直接用整数分片键对分片数取余数。SQL层面的表达大概是这样的：

-- 假设分成 32 张分表 -- 传统取模方式：分表序号 = (订单ID % 32) SELECT * FROM orders_8 WHERE order_id = 10086;

应用层做的事情是拦截SQL、解析出分片键的值、计算出目标分片、改写表名、再把这个查询发到对应分片上。一个完整的取模计算逻辑大致如下：

public class ShardRouter { private static final int SHARD_COUNT = 32; public String route(String fieldName, Object fieldValue) { int hash = fieldValue.hashCode(); int index = Math.abs(hash) % SHARD_COUNT; // 返回分片序号对应的物理表名 return "orders_" + index; } }

取模算法的优点是人人都能看懂、实现简单、数据分布也很均匀。但它有一个非常大的隐含约束：分片数量一旦确定，后期扩容就会非常痛苦。如果线上分32个分片，加到64个，那么所有历史数据里有一半需要从旧分片迁移到新分片，因为原来的取模结果全变了。这就是大量团队宁愿用"虚拟桶"、范围分片、一致性哈希来规避的原因。

另一种常见的分片方式是范围分片，按时间或者按ID区间划分。比如order_id在1到1000000落第一片，1000001到2000000落第二片。范围分片的优势是扩容方便——数据量涨到一定阈值直接新增一片就行，不用动历史数据；劣势是容易产生热点，比如按时间分片的情况下，当前时刻的写入会全部打到最新那个分片上。实际项目里，很多人会采用"时间范围分片 + 应用侧定期归档"的策略，这算一种规避热点的实践，但对运维要求更高。

2.3 全局主键：自增主键退出后的替代方案

分库之后，原来的自增主键就用不了了。理由很简单：每个分片各自维护一套自增，全局主键一定会冲突，即使把初始值和步长错开，也无法保证全局唯一。

业界最常用的主键生成方案是雪花算法。它的核心思想是把一个64位的ID拆成几段：最高位是符号位，接下来是毫秒级时间戳，然后是机器编码，最后是同一毫秒内的自增序号。这样一个ID天然带着时间有序性，同时能在全局范围保持唯一。

雪花算法实现起来不难，但有一个经典坑叫"时钟回拨"。如果部署的机器NTP时间校准导致系统时钟往后退，就在同一毫秒内出现了两个相同的时间戳和序号，主键就可能重复。很多成熟实现都会在检测到时钟回拨时短暂暂停发号，等待时钟追平。这里我想说的是，不要觉得主键生成是件小事，在分库分表架构里，主键就是全局数据的唯一身份，一旦冲突，后面做数据校验、对账、幂等处理时全都会出连锁问题。

2.4 扩容为什么比第一次拆分更痛

第一次拆分时，系统通常还没有太多历史包袱，脚本一跑、全量迁移就完事了。但扩容是在系统运行状态下的在线操作，最典型的问题是：原来的取模规则是"分片键 % 32"，你改成"% 64"之后，大部分旧数据的位置变了。

要解决这个问题，有两种主流思路。一种是虚拟桶方式：先分固定数量的虚拟桶，比如1024个桶，将桶映射到物理分片；扩容时只调整桶到分片的映射关系，数据迁移量从"几乎全部数据"缩小到"被重新映射的那部分桶"。另一种是双写迁移方式：新旧两套规则并行，旧数据按旧规则继续读，新写入按新规则同时写两份，迁移完再切读流量。

无论选哪种，扩容这件事都建议先做演练，而不是在生产环境直接执行。这条经验后面会在迁移章节里再展开。

3. 框架选型的关键差异：两条路线的博弈

"分库分表框架"这个词涵盖的范围其实很广。在我接触过的项目里，真正投入生产的实现形态有几类，它们解决问题的路径、对应用的影响、对团队的要求完全不同。选型之前，先理解它们之间的本质区别，比背参数列表有用得多。

3.1 客户端中间件形态

客户端中间件的本质，是在应用内部集成一层路由和数据访问层。应用仍然像操作普通数据源一样操作数据库，但这层中间件会拦截SQL、解析分片键、改写SQL、把请求路由到正确的分片、再将结果合并返回。

这种形态最明显的优点是性能损耗小，中间件和应用同进程运行，没有额外的网络跳转；部署也简单，只需要引入一个依赖，不需要额外运维一套服务。缺点同样明显：它对应用有侵入性，应用代码里需要配置分片规则，团队必须理解分片逻辑；SQL支持范围受限，遇到复杂的多表关联、子查询、跨分片聚合，要么改写，要么放弃。此外，连接管理、监控、分布式事务这些能力都要依赖中间件自身的完成度。

适合这种形态的团队是：有Java技术栈基础、业务本身是集中式单体、团队愿意花精力理解和使用它的规则，且分片逻辑较为稳定。如果你是一个新项目，数据规模已经可以预期会快速增长，那这个形态的性价比是不错的。

3.2 服务端代理形态

服务端代理的典型做法，是独立部署一个代理服务，应用连接这个代理，就好像连接一台普通的数据库服务器；代理负责解析SQL、按规则路由到底层分片、合并结果，最后把结果返回给应用。应用侧完全感知不到分片的存在。

这种形态最大的好处是透明。业务代码改动量小，原有数据源连接串只需要替换成代理地址，分库分表对上层应用几乎不可见。同时，因为代理是集中部署的，规则调整、监控、限流、审计这些能力可以在一个地方统一管理。代价是性能上多了一跳，所有请求都必经代理，代理会成为新的性能和可用性瓶颈点；如果OLTP请求量很大、网络开销很敏感，需要仔细评估延迟增量是否可接受。代理形态的运维复杂度也更高，相当于额外维护一套数据库接入层基础设施。

适合这种形态的场景是：存量系统改造、团队不想改大量应用代码、多个业务线共用数据库基础设施，或者需要一个统一管理分片规则和数据访问策略的平台。

3.3 两种形态的量化对比

在实际选型中，常用一张表格把关键差异摆出来，让团队根据现状去打勾。

这里补充一点：现在还有一种原生分布式数据库的路线，它把"分片"内化到存储引擎本身，应用连接它就像连接一个普通数据库，分片和事务由数据库层自动完成。这个方向的吸引力很大，但引入它意味着整个存储层要迁移到一套新的基础设施上，稳定性、周边工具链、团队经验都要求更高。它更适合数据规模极大、也有条件做基础设施重构的团队；大部分业务场景，用上面的两种形态之一可能更务实。

框架选型的最终决定因素，其实不是技术参数的差异，而是团队当前处境。我见过一个团队图省事选了代理形态，却因为代理层高压下的稳定性问题耗费了大量排障时间；也见过另一个团队坚持用客户端中间件形态，结果因为业务多团队共库连接复用不当，最后被迫重做。选型不是选最先进的那个，而是选最有把握驾驭的那个。

3.4 如果确实需要自研，核心要做什么

有些团队因为所处技术栈特殊，或者对公共组件依赖保持谨慎，会选择自研一套轻量分库分表组件。这条路如果必须走，我建议先想清楚范围：不要指望自研解决所有问题，只需要把最核心的"路由 + 结果合并 + 配置管理"做扎实。

自研分库分表，最核心的部分是SQL解析。用正则表达式硬解析SQL是不可行的，复杂查询会把你拖垮，必须依赖语法树级别的解析器，识别出查询条件和合并逻辑。第二个核心是结果合并，跨分片的order by和limit要做归并排序，这部分的边界情况很多。第三个是分片规则的配置化，要把分片算法和管理后台打通，而不是写死在代码里。如果这三件事没有把握做好，我建议认真考虑使用开源方案，而不是自研。

4. 迁移与回滚：分库分表落地的完整动作

分片规则设计好了、框架也选好了，接下来最考验实战能力的一步是数据迁移。我见过太多项目在方案评审时激情澎湃，最后死在了迁移这关。数据库迁移的本质是"在不停机的条件下，把一套完整性要求很高的数据，从旧系统搬到新系统，并且保证过程可回滚"。

4.1 迁移前必须完成的准备

开始迁移之前，有三样东西必须准备到位，缺一样都不要开工。

第一，新旧两套结构的映射关系要提前确定。也就是每一条旧表记录，落到新库的哪一个分片、对应的新表名是什么。这个映射关系不是靠脑子想的，需要开发一个映射脚本，在测试环境用真实的存量数据跑一遍，验证路由算法的正确性。第二，数据校验工具要提前开发好。一会儿我会单独讲校验的逻辑，但核心原则是：校验工具的上线时间必须早于迁移链路的上线时间。第三，回滚开关要提前设计。迁移过程中任何异常，都要能一键把读写流量切回旧库，这个开关必须在动第一行数据之前就已经验证过。

4.2 存量全量+增量同步的双写方案

线上迁移的标准打法是双写方案。具体分四步走。

第一步，做一次全量快照迁移。用数据库导出工具把旧库数据导出来，通过映射脚本按新规则写入分片库。这一步通常在低峰期执行，导数据期间业务读照常，写暂时不阻断，但要评估时间窗口。第二步，启动增量同步。从全量快照开始的位点启动增量同步，旧库的新增、更新、删除操作都要实时同步到新库。应用程序可以把写操作同时发一份到MQ，让消费端把变更写到新库；也可以用数据库自身的主从复制链路，把旧库的binlog解析后写入新库。第三步，双写的同时读流量还是走旧库，校验两侧数据持续一致。第四步，当增量同步的延迟归零、且数据校验连续通过，再切换读流量到新库。切换顺序上，先切读流量、观察稳定后再切写流量，更多团队会同时切或先切写再切读，但稳妥起见，按照"读先行、写跟后"的策略不容易翻车。

伪代码示意如下：

// 双写逻辑示意 function writeOrder(order) { // 先写老库，保持业务连续性 oldDB.insert(order); // 异步发送变更事件给增量同步消费端 mq.send("order_changed", order); // 增量消费端同步到分片库 }

4.3 数据校验与对账：怎么确认两边真的一样

数据校验是迁移过程中最容易出问题的环节。数字对不上不一定代表迁移出错，也可能是校验方法本身不合理。我做校验一般分三层。

第一层是总量校验。统计旧库和各分片库的每条分片对应的记录总数，如果两边对不上，说明迁移链路有严重的丢数据问题。第二层是抽样字段校验。每条记录可以按主键取若干核心字段的哈希值，做全量或抽样比对。全量比对如果数据量太大，可以按分片粒度、按时间段分批做。第三层是实时增量对账。在双写阶段，定时统计一个时间点之后两边的新增、变更记录数，确认增量链路没有丢消息。这里有个经验：校验任务本身尽量用低优先级执行，别让它影响业务读写。

4.4 灰度切流与回滚预案

全量切换是黑色的风险操作，必须拆成灰度步骤。可以按用户ID区间灰度，也可以按分片逐个灰度，还可以按入口流量比例灰度。例如先把2%的用户逐步切到新库，观察一段时间，没有异常再扩大比例。

灰度期间要盯的指标包括：查询响应时间、慢SQL数量、分片库的连接数、数据同步延迟、业务侧的报错率。任何一个指标异常，立即触发回滚。回滚的动作就是把路由配置中的目标库整体切回旧库，只要旧库仍然在正常接收写入，回滚就是可行的。所以要特别注意，在完全确认新库稳定之前，旧库的写入口不能提前关闭。

我个人的习惯是，迁移完成后至少保留旧库一段时间的只读状态，特别是要跨一个业务周期的数据验证之后，再真正下线旧库。多留一天，就多一天后悔药。

5. 跨库难题：分布式事务与分布式查询的处理

分库分表上线之后，你会很快发现，开发们开始频繁遇到一个非常具体的问题：原本在一个事务里能完成的多个更新操作，现在跨分片了，怎么办？原本一条JOIN能查询的数据，现在分布在多个库，怎么办？这一章专门讲这两个分布式难题的务实解法。

5.1 分布式事务：能避免比能用更重要

很多人第一时间想到分布式事务方案，比如XA强一致事务、TCC补偿模式、本地消息表+最终一致。但我必须先给一个反直觉的建议：分布式事务最好的处理方式是避免分布式事务的发生。

怎么避免？答案是设计分片规则的时候，把需要强一致的关联数据放在同一个分片里。比如订单场景，一个用户的订单和订单明细天然应该落在同一个分片，那么"创建订单 + 写订单明细"这个原子操作就仍然是单库事务，不涉及分布式。类似地，账户场景里，一个用户的所有账户数据放在同一分片，转账操作就只需要保证本分片内的强一致。

总有一些场景无法避免跨分片，那种情况下常用方案有两种。可靠异步最终一致是首选，核心做法是：本地事务里先把业务数据和消息状态写入同一张业务表，然后异步发消息给下游，下游消费后更新另一分片的数据。如果下游处理失败，消息会重试，直到成功。这种方案的复杂度在于消息表与业务表的一致性维护，但只要做扎实，可靠性很高。另一种是TCC模式，它是企业对实时性要求很高时的选择，Try阶段预留资源、Confirm阶段提交、Cancel阶段回滚。TCC的问题在于代码侵入非常强，每个业务操作都要实现三套逻辑，开发成本高、测试复杂，我建议只在核心资金类链路里使用。

5.2 跨库Join的替代方案

分库之后，"订单表关联订单明细表再关联商品表"这类经典的SQL查询基本就告别了。替代方案按场景主要有三种。

第一种是宽表冗余。把查询视角最常用的字段直接冗余进主表。比如订单列表页需要商品名称、商品主图，那就把这两个字段冗余存储在订单表里。商品名称变更时，需要异步回写订单宽表，这个回写虽然有一致性延迟，但对大多数展示型场景没问题。这是最常见的方案，也是开发最欢迎的方案，因为应用层的查询简单直接。

第二种是应用层聚合。先按分片键查出主数据，再根据主数据里的业务ID拼出二次查询条件，逐条去查关联表，最后在应用内存里做合并。这种方案的缺点很明显：N条主数据就产生N次查询，最多只能扛住小批量。我只建议在数据量可控、低并发的后台场景使用。

第三种是建立全局只读汇总库。把分片库的核心数据通过实时同步汇总到一个独立的宽表数据库，供报表、运营后台这类跨分片查询使用。这个方案实际上是把"查询需求"从分片库系统里剥离出去，让在线分片库保持轻量。值得提醒的是，汇总库的同步链路需要特别监控，否则会出现报表数据延迟的问题。

5.3 深分页、排序和聚合的暗礁

跨分片分页是最容易被低估的问题。一个看起来很简单的查询，比如"按时间倒序取第10001到10020条"，在没有分片时，数据库可以从索引定位到偏移位置，返回20条数据。但在分片环境下，你需要从每个分片里各取前10020条，然后在应用层归并排序之后，再截取第10001到10020条。数据量越往后翻，每条分片需要取出的数据就越多，性能雪崩很快。

这带来几个实战经验：业务上不要提供可任意跳转的深分页，比如"跳到第1000页"，这类需求可以直接和产品沟通使用"上一页/下一页"的游标模式替代。实现游标分页时，排序字段最好使用唯一且单调的字段，比如主键或创建时间加主键的组合，否则相邻两页之间可能出现数据重复或遗漏。对于后台管理这类确实需要深分页的页面，宁可把数据先同步到汇总库，再从汇总库里做复杂查询，也不要让分片库直接扛。

6. 实测中容易踩的坑与排查经验

这一章集中写我上线分库分表架构之后真实踩过的坑。很多问题在设计阶段看不出毛病，只有线上压力来了才暴露。把这些经验提前给你，能省不少半夜上线的惊吓。

6.1 分片键隐式转换导致的全库穿透

有一次我们排查一个线上慢SQL，发现原本应该走分片路由的很简单的等值查询，竟然把32个分片全扫了一遍。原因非常隐蔽：业务表里分片键字段是varchar类型，但代码里传进来的参数是Long类型。数据库在比较时做了隐式类型转换，导致中间件解析SQL时无法确认分片键的值，只能退化成全路由扫描。解决方式很朴素，一是应用层统一参数类型，二是分片键的字段类型定义保持绝对的稳定一致，三是监控里增加对"全路由扫描"的告警。这类坑的麻烦点在于不是必现，只有特定数据类型组合才会触发，排查路径往往要从执行计划里看到"扫了所有分片"才能暴露。

6.2 源于条件字段不完整的事务路由

常见的一个设计缺陷，是同一个表存在两个不同的分片维度规则，而代码里有时只传了其中之一的字段过来。比如下单时按user_id做路由，但取消订单的接口只传了order_id。于是取消订单的请求就会经历一次全分片扫描，先找到订单再执行更新。平时单量少的时候没事，一旦某个大促场景大量取消订单，全表扫描请求会瞬间把连接池打满。

规避方案有两个层面。第一个层面，如果确实存在这类二次查询场景，需要给中间件配置"反向索引表"或"分片映射表"，用order_id直接定位user_id，然后走精确路由。第二个层面，业务接口的设计上必须从源头带齐分片字段，比如取消订单时把user_id也一并传过来。这需要和上游调用方定好契约，一旦遗漏就是线上事故级别的坑。

6.3 深分页打爆一个分片的内存

有一回线上监控显示某个分片库的内存持续飙升，后来定位到是一条跨分片的分页查询导致。语句本身看起来人畜无害，就是普通的分页列表，但因为排序字段在分片键上不具备全局顺序性，中间件需要对每个分片先把大量数据加载到内存做归并排序。当并发量上来时，内存十几G地涨，直接把分片库的Buffer Pool挤掉大半，业务查询整体变慢。

这个教训让我后来在分片架构里对所有的分页查询都做了强制约束：凡是跨分片的order by + limit，必须使用游标模式且限制单页大小；凡是后台报表类的跨分片聚合，一律走汇总库。不要相信"偶尔有人点一下没事"这种侥幸，分页查询在运营后台就是高频操作。

6.4 线上数据一致的排查思路

分库分表后，出现数据不一致是早晚的事，关键在于怎么快速定位是哪一环出了问题。我总结的排查链路是：先看增量同步的消费位点是否有积压，积压会自然导致新旧数据不一致；再查消息或同步任务的重试次数，有没有持续失败的记录；接着按主键逐个分片抽查样本，确认是单条数据丢失还是批量数据路由错位；最后回查路由日志，确认应用侧在执行写操作时计算出来的分片序号是否符合预期。

实际过程中，最容易被漏掉的是路由日志。很多团队上线分库分表却不记录每次SQL请求的路由结果，等到出问题只能抓瞎。这是一个不太起眼但价值很高的细节：中间件侧输出一条携带分片序号的访问日志，能做路由合理性分析、能做容量规划、也是排查问题的第一道线索。建议所有使用分库分表的团队都必须把这个日志加上。

最后再分享一点个人经验：分库分表上线之后，不要急着关掉旧库，也不要急着把运维监控的粒度做得太粗。把分片数量、各分片连接数、当前路由方式、数据校验结果这些指标都沉淀到团队的基础设施里，让每次排查问题都有依据可查。这套东西的完善程度，往往决定你是被分库分表救了，还是被它拖进了更深的坑。