MySQL分库分表策略解析：从评估到落地的完整指南-平芜编程栈

1. 为什么需要分库分表：先搞清楚你要解决什么问题

聊到 MySQL 分库分表，先得泼一盆冷水：这东西不是银弹，更不是用来炫技的。很多同学学到这一章的时候，往往已经写了不少业务代码，对 CRUD 已经非常熟练了，于是看到“分库分表”四个字就觉得是处理高并发的灵丹妙药。但实际上，我在实际项目里见过太多因为过早分库分表而把架构搞复杂、把开发效率拖垮的案例。所以这一章我不会上来就列各种中间件的配置教程，而是想先和大家一起把“为什么要分库分表”这个问题想透。

从本质上看，你之所以要考虑分库分表，无非是遇到了下面几类问题：

第一类是单库连接数或性能瓶颈。当你的应用实例从一两台扩展到几十台的时候，每个实例都要和数据库建立连接池，单库能扛住的连接数是有限的，数据库端的 CPU、内存、IO 首先就吃不消。

第二类是单表数据量过大。一张表数据量上了千万、上亿之后，即使索引建得再合理，B+ 树的层级变深，磁盘 IO 次数变多，查询性能也会明显下降。索引占用的空间大，缓存命中率也直线降低。这时候你会发现，明明 SQL 已经优化到头了，但响应还是慢。

第三类是写入吞吐量受限。单库的写入能力受限于磁盘 IO 和主从同步的延迟，你在一个库上做高并发写入，binlog 的产生速度、从库的回放速度都会成为瓶颈。

你要明白，分库分表是架构层面的重操作，一旦上了这个方案，你的系统复杂度会呈指数级上升。事务处理、跨节点 join、分布式 ID、数据迁移、后期扩容，每一样都得小心应付。所以这一章的重点不是“怎么分”，而是“怎么判断要不要分、怎么分最合理”。换句话说，这是一套考量的策略。

如果你刚接触这个概念，可以先在脑子里建立一个整体印象：分库分表解决的是“量大、并发高”这类问题，它是在数据层做的一种物理拆分手段。你读完之后未必马上用得上，但当你真的有一天在面试里、在系统设计里碰到“高并发大数据量存储”题目，你会发现这一章给你搭起了一个完整的决策框架。

2. 先分清楚：分区、分表、分库到底有什么不同

很多初学者会把分区（Partition）、分表（Sharding Table）、分库（Sharding Database）搅在一起，觉得都是“把数据切开”。这个误解非常危险，因为三者的实现原理和适用场景完全不同。

2.1 分区是 MySQL 内部的行为

分区是在同一张表、同一个数据库实例内部，把一张逻辑上的表按照某种规则（比如按范围、按取模、按列表）拆分成多个物理存储片段。对应用层来说是透明的，你依然操作“一张表”，MySQL 引擎会自动定位数据落在哪个分区。

举个例子，订单表可以按年份分区：

CREATE TABLE orders ( id BIGINT, order_no VARCHAR(32), created_at DATETIME ) PARTITION BY RANGE (YEAR(created_at)) ( PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025) );

这种方案的好处是：对代码零侵入，某些场景下（比如清理历史数据）直接 drop 一个分区即可，效率极高。但它的本质瓶颈没有消除？数据还是在一台机器的同一个实例里，连接数、磁盘 IO 的瓶颈依旧。所以它适合数据量中等、定期归档、单机还能撑住的场景。

2.2 分表通常是应用层路由

分表则是把一个表的数据按照某类规则分散到多张物理表中，这些表通常还在同一个库，甚至同一台机器上。应用层需要自己感知路由规则，去决定“这一条记录该查哪张表”。常见做法是：

-- 假设按照用户 ID 取模分成 4 张表 -- 表名：order_0、order_1、order_2、order_3 SELECT * FROM order_$ {userId % 4} WHERE user_id = 12345;

分表能明显降低单表的数据量和索引体积，提升查询效率。但如果是同一台机器，CPU、内存、磁盘 IO 依然共享，写入能力的提升有限。如果你把表分散到不同机器上，那就涉及到“分库”了。

2.3 分库是物理隔离的手段

分库就是把不同的表或者同一张表的不同数据片段，放到不同的数据库实例上，做到物理隔离。这样才能真正解决“单库连接数、单机 CPU、磁盘 IO”的瓶颈。

你把用户库和订单库分开，让不同业务域各用各的资源池；或者同一个订单库按照取模拆成 4 个库，每个库落在独立机器上——这才叫分布式数据库架构。

2.4 三者组合的现实选择

在实际项目中，我见过最常见的一套组合是：先垂直分库，再水平分表。节奏是先把不同业务模块拆到不同库，比如 user 库、order 库、product 库，然后针对其中数据量特别大、增长快的核心表再做水平拆分（分表）。如果单一实例的压力还是大，再考虑把分出来的表放到独立实例上（分库）。

这里给出一张对比表，方便你理解：

维度	分区	分表	分库
是否对应用透明	是	否	否
数据分布范围	单实例内	单实例或多实例	多实例
是否解决连接数瓶颈	否	否	是
是否解决单表数据量大	有限解决	解决	解决
代码侵入性	无	有（路由逻辑）	有（数据源路由）
典型应用场景	按时间归档、冷热分离	单表数据量大、写入增长快	高并发、多业务域隔离

我特别提醒一点：不要上来就想着分库分表。如果你的系统日均请求量只有几千、几万，单表数据量不过几百万，把索引建好、SQL 写好、引入缓存和消息队列，90% 的性能问题都能解决。分库分表的引入一定要靠数据说话，而不是靠“感觉流量要涨了”作为依据。

3. 两种拆法：垂直拆分和水平拆分怎么选

分库分表从拆分的维度上又分两种：垂直拆分和水平拆分。这两个概念看似简单，但里面有很多细节值得展开说。

3.1 垂直拆分：按业务域或字段拆

垂直拆分有两种理解层次，对应两种落地方式。

第一种是按业务域拆库，也就是把一个系统中耦合在一起的表，按照业务归属拆到不同库。比如用户相关的表进 user 库，商品相关的表进 product 库，订单相关的表进 order 库。每个库可以由不同的团队负责 DDL 权限、容量规划、监控告警，互不干扰。

第二种是按字段拆表（也叫垂直分表），针对某一张“大宽表”，把频繁查询的字段和不太常用的字段、超大的文本字段拆成两张表，通过主键关联。典型场景是商品详情表，商品描述这种 TEXT 类型字段又大又不常查，硬塞在主表里会严重影响行大小和缓存效率。

我做一个实际案例模拟：假设有个product表，字段有id, name, price, stock, description, created_at, updated_at, owner_id。其中description是超长文本，且商品列表页只需要前六个字段。那你可以拆成两张表：

CREATE TABLE product_basic ( id BIGINT PRIMARY KEY, name VARCHAR(128), price DECIMAL(10, 2), stock INT, owner_id BIGINT, created_at DATETIME, updated_at DATETIME ); CREATE TABLE product_extra ( id BIGINT PRIMARY KEY, product_id BIGINT, description TEXT );

查询列表时只查product_basic，行体积小、一页数据多、缓存命中高。真正需要详情时再通过 ID 查product_extra。这个手法很基础，但很多人一开始建表时没这个意识，等到表和索引都大了再重构，成本就高了。

3.2 水平拆分：按数据行拆

水平拆分是“同一张表，按数据行拆分到多张表/多个库”，每张表的结构完全相同，只是数据范围不一样。比如把 1 亿条订单数据按照用户 ID 取模，分散到 16 张表里，每张表 625 万条。

我来带你们走一遍选择策略的过程。假设你有一个订单表，当前数据量 4000 万，每天新增 40 万，三年后大约到 8000 万。你想做水平拆分：

先定总容量目标：假设一张表最舒服的数据量是 1000 万以内。那 8000 万至少需要 8 张表。
再考虑后两年的增长：留出余量，直接定 16 张（2 的幂次方）。
最后决定是分表还是分库：如果单个 MySQL 实例能扛住，只在同一库里分 16 张表即可；如果单实例的 IO 和连接数也有压力，就拆到 2 个实例，每个实例 8 张表。

这里我强烈建议分表数量取 2 的幂次方：2、4、8、16、32。为什么？因为后面做数据迁移扩容时，2 的倍数方便对半迁移（把 8 张表的数据均衡搬到 16 张表时，取模规则从id % 8改成id % 16，可以把关键节点对齐）。实际扩容时最常用的平滑手段之一就是“对半扩容”，而 2 的幂次方天然支持这种操作。

3.3 先垂直还是先水平

我的建议非常明确：先垂直拆分，后水平拆分。先垂直能把不同业务域的相互影响彻底隔离开，同一时间只有核心的订单表可能数据量大；水平拆分解决的是单张表内部的量级问题，它是更底层的操作，通常垂直拆分做完之后，你才会真正看清哪些表才是需要水平拆分的。

过早水平拆分最大的问题在于：你还不确定哪个是核心表、哪个字段会怎么演化，就把路由规则写死了。等到业务调整，或者字段变更时，所有跨表操作都变成噩梦。所以稳妥的路径是：单实例 → 读写分离 → 垂直拆库 → 对核心表水平拆表。这一步一步来，每一步都能单独回退，架构演进的风险可控。

4. 分片键怎么选：这是决定生死的关键决策

水平拆分你会遇到一个绕不过去的核心问题：用哪个字段做分片键（Sharding Key）。这个决策直接决定你后续所有查询能不能路由到正确的库/表。

4.1 分片键的基本要求

一个合格的分片键需要满足三个条件：

数据分布均匀：取模之后各个分片的数据量不能差别太大，否则会出现“数据倾斜”，有的分片闲着，有的分片快撑爆了。
查询条件能带上：绝大多数查询语句里必须带上这个字段，否则就要全分片扫描。
值基本稳定：分片键的值一旦确定就很少变更。如果分片键本身的值会变（比如用户名、手机号可能变更），那数据迁移就是一场灾难。

4.2 具体场景怎么选

不同业务有不同的天然分片键。我列几个最常见的：

业务场景	推荐分片键	原因
订单表	用户 ID 或商户 ID	用户查询自己订单是主流需求
消息表/会话表	用户 ID	按人维度查询会话记录
商品表	商品 ID	商品详情、列表都基于商品 ID
流水表/日志表	时间字段	天然按时间范围聚合

需要注意的是，不可能做到用一个分片键满足所有查询维度。你选了用户 ID 作为订单表的分片键，那么按商户维度去统计订单量就会很痛苦，因为同一商户的订单散落在各个分片上。面对这种问题，现实的做法一般是：

主分片键满足最高频的查询场景；
对次高频场景，通过“冗余表”或者“索引表”来解决。比如建立一个商户和用户之间的映射关系表，或者按商户维度再冗余一份订单统计表；
对低频的跨分片查询，接受全分片扫描，或者离线跑数。

这里我要特别提醒：不要在分片键上使用随机值（比如 UUID）。随机值看似分布均匀，但它完全丧失了时间局部性，最常见的“最近订单”这种范围查询就没法直接在单分片上完成了。UUID 做主键还会导致 B+ 树页分裂严重，索引碎片加剧。真实项目中我看到用 UUID 做主键然后又想分表的，几乎没有一个不后悔的。

4.3 取模还是范围

分片规则最常用的是两种：取模和范围。

取模（比如user_id % 16）的优势是数据分布非常均匀，劣势是范围查询（比如查最近一周的订单）会被拆解到所有分片，然后内存里归并。范围（比如按月份、按时间区间）的优势是范围查询非常高效，劣势是数据可能集中在近期分片，出现“热点”，而且每个分片的数据量会很不一样。

有些团队用“范围+取模”的组合，比如“先按年份分库，再按用户 ID 取模分表”，这样既保留了时间维度的归档便利性，又能让同一年内的数据在各分片上均匀分布。这个组合我实际用过，整体效果尚可，但要注意两层路由的复杂度和后期扩容的灵活性之间有取舍，你得评估团队能不能驾驭。

4.4 分片键选错了怎么办

聊一个很少有人系统性讲的话题：分片键选错之后，怎么补救？

首先，如果只是路由不均匀，可以尝试“基因法”改造分片键。所谓基因法，就是新的分片键里既包含了业务时间信息，又带上原始 ID 的取模因子。比如原始订单号是订单时间戳 + 6位随机数，你可以在生成订单号时，让最后两位直接取user_id % 100的结果，这样既能按时间范围查，又能精确路由到某个分片。

其次，如果分片键的查询维度确实无法覆盖新增需求，那就老老实实引入宽表或者搜索引擎（ES 是比较稳妥的方案）。把跨分片查询的场景导到 ES 里去解决，MySQL 只承担一致性要求最高的核心事务。

最后，等到数据量实在太大、需要重新分片时，你会面临一次完整的数据迁移。我的建议是做好双写、校验、切流三步。这块我在下一个小节会详细讲。

5. 实操：一次完整的水平分库分表设计案例

这一节我带着大家实际走一遍设计过程。场景是一个典型的电商系统，其中订单表是系统的核心表，目前已经有 1 亿条数据。需求是支持三千万注册用户的日常订单查询和商家订单管理。

5.1 确定总数据量和分片数

先给一个容量估算的基本公式：假设单表最优数据量为 N 条，未来两年的数据量为 M 条，则分片数 = M / N，向上取整到 2 的幂次方。

以订单表为例：

当前 1 亿条，日均新增约 50 万条；
两年后：1 亿 + 50 万 × 730 ≈ 3.65 亿条；
单表按 1000 万条控制：需要 36.5 张表，取 2 的幂次方为 64；
考虑到单实例能否支撑 64 张表的活跃度和连接数，如果一台机器比较吃力，可以拆到 4 个实例，每个实例 16 张表。

最终方案：4 个库 × 16 张表 = 64 个分片，每个分片约 570 万条。

这里读者可能会有疑问：为什么单表要控制在 1000 万？这个数字不是绝对的，和你的行大小、索引数量、存储引擎有关。行小、索引少的表，2000 万也可能没事；行大（比如包含 TEXT/BLOB）且索引多的表，可能 500 万就开始明显退化。所以容量估算时你要先量一量自己的行大小。

5.2 路由规则设计

我们选择用户 ID 作为分片键，路由规则是：

-- 分库：user_id % 4 -- 分表：(user_id / 4) % 16

这个双层路由设计的意图是：同一个用户的所有订单永远落在一个库里，同库内的表再按区间细分。这样按用户查订单，只需要路由到 1 个库的 1 张表，效率最高。

5.3 建表和索引设计

分片之后，每个分片上的表结构如下：

CREATE TABLE `order_0` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `user_id` BIGINT NOT NULL, `order_no` VARCHAR(64) NOT NULL, `merchant_id` BIGINT NOT NULL, `order_status` TINYINT NOT NULL DEFAULT 0, `total_amount` DECIMAL(10, 2) NOT NULL, `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里我解释一下索引设计的思路。主键还是自增 ID，但order_no必须有唯一键。为什么不用订单号直接做主键？因为如果订单号里拼接了路由因子，可能长度较长，InnoDB 的主键过长会拖慢二级索引的效率。idx_user_id (user_id, created_at)是核心查询索引，支撑“查某用户某个时间段的订单”这个最高频场景。

实际生产环境中，分布式 ID 也不能依赖 MySQL 自增了。一般用 Snowflake 算法或号段模式生成分布式 ID，保证全局唯一、趋势递增。趋势递增这一点很重要，因为它能让主键索引的写入保持顺序性，减少页分裂。如果使用完全没有规律的 ID，写性能会明显变差。

5.4 应用层的读写实现

分库分表后，应用层必须自己维护路由。最简单的方式是写一个路由工具类：

public class OrderShardingRouter { private static final int DB_COUNT = 4; private static final int TABLE_COUNT = 16; public static String routeDB(Long userId) { return "order_db_" + (userId % DB_COUNT); } public static String routeTable(Long userId) { long dbIndex = userId % DB_COUNT; long tableIndex = (userId / DB_COUNT) % TABLE_COUNT; return "order_" + tableIndex; } public static String routeFull(Long userId) { String db = routeDB(userId); String table = routeTable(userId); return db + "." + table; } }

我特别想强调一个细节：(userId / DB_COUNT) % TABLE_COUNT这个双层路由公式的重要性。如果直接写成userId % (DB_COUNT * TABLE_COUNT)，就无法保证同一个用户的订单落在同一个库里。因为对 64 取模的结果虽然唯一对应一个分片，但这个分片既可能在一个库的某张表，也可能在别的库的某张表，同一用户的数据会被拆到多个库。所以必须用双层路由，先确定库，再在库内确定表。

这是整个路由设计中最容易踩坑、最容易理解错的地方，也是面试中非常爱考的细节。我之所以用user_id % 4来决定库，就是为了保证同一个用户的订单永远在同一库里。这是水平拆分的基本原则：同一个分片键值的数据必须被路由到同一个分片。

6. 分库分表后那些绕不开的“麻烦事”

分库分表之后，很多面试题里你会见到的技术点，都是围绕这些麻烦事展开的。我自己带过不少团队，在这方面踩过的坑也很多，逐一讲一下。

6.1 分布式事务怎么做

单库的时候，用BEGIN...COMMIT能搞定的事务，分库后就力不从心了。跨库的多个写操作，本质上需要分布式事务来保证一致性。

目前主流的方案有三种：

XA 两阶段提交：强一致性，但性能较差，对资源锁定时间长，不适合高并发场景。实际项目中我极少用。
TCC（Try-Confirm-Cancel）：补偿型事务，需要业务代码里实现 Try、Confirm、Cancel 三段逻辑，侵入性强，但性能好，适合对一致性要求较高的场景。
本地消息表 + 消息队列：最终一致性方案。核心思路是“业务操作 + 消息写入”在同一个本地事务里完成，然后通过消息队列异步通知下游消费。一致性的时效性比 TCC 低一点，但实现简单、性能好，是大多数互联网业务的首选。

我举一个简单的最终一致性示例：用户下单后需要扣库存、生成订单。订单在 order 库，库存却在 product 库。此时你在一个事务里先写订单表的记录，再往本地消息表插入一条“扣减库存”的消息，两个动作在同一个本地数据库事务中提交。然后一个异步任务扫描消息表，把消息通过 MQ 发到库存服务，库存服务消费后更新库存表。整个流程保证了业务操作和消息记录的一致性，到时库存服务挂了还能重试。

6.2 跨分片 JOIN 和分页排序

分库分表后，“订单 join 订单明细”“订单 join 商品”这种 SQL 基本写不了了。我的经验是：

通过字段冗余来消灭 JOIN，这是最简单的办法。例如在订单表里冗余一份商品名称和商品快照价格，查询时可以只查订单表。
必须 JOIN 的，可以在应用层先查出主表数据，再批量查关联表，最后内存组装。虽然多了一次 RPC，但性能和可控性都更好。
有些后台管理系统需要多表关联做复杂统计，我的建议是同步到 ES 里做宽表，MySQL 只承接联机事务。

分页排序的问题是另一大坑。LIMIT 10 OFFSET 100000这种查询在分库后会变成：每个分片都得查出 ”偏移量 + 页大小“ 这么多数据，然后应用层再归并排序，工作量随偏移量线性增长。遇到深分页，我建议改成“游标分页”：不传页数，传上一次查询的排序字段的最大值，比如WHERE created_at < '2024-03-01 12:00:00' ORDER BY created_at DESC LIMIT 20。这能避免全分片大偏移。

6.3 数据迁移与回滚方案

无论你是第一次分库分表，还是因为扩容需要从 8 个分片扩到 16 个分片，数据迁移都是最难的部分。最稳妥的步骤是“双写 + 校验 + 切流”。

具体来说：在迁移期间，写入操作同时写入旧库和新库；跑一个离线任务把历史数据同步到新库；然后对账校验两边的数据一致性。确认一致后，再把应用的读流量逐步切到新库上。切流一定要灰度：先切 5% 流量，观察一段时间，再逐步提升到 100%。一旦出问题，只要把流量切回旧库即可。

在这个过程里，我提醒几个容易犯错的地方：

双写阶段一定要保证写入顺序，先写旧库还是先写新库，务必标记好，否则回滚到旧库时数据可能错乱。
数据校验不能只看数量一致，字段级别的关键字段（比如金额、状态、更新时间）也得抽样比对，否则可能出现“数量一样，内容不对”的尴尬。
迁移期间对业务最重要的指标是延迟：同步任务不能拖垮线上主库，建议在从库上跑历史数据同步，或者限制同步任务的并发。

6.4 分布式 ID 生成

分库分表后，自增主键在全局来看会重复，所以必须使用分布式 ID。我比较推荐的是雪花算法（Snowflake）和号段模式两种。

雪花算法的结构是：1 位符号位 + 41 位时间戳 + 10 位工作机器 ID + 12 位序列号。单机一毫秒能生成 4096 个 ID，趋势递增，性能高。但要注意“时钟回拨”问题：一旦服务器时间回拨，生成的 ID 就可能重复。险一点的处理是在生成时判断当前时间戳是否小于上次时间戳，如果小于，则等待或直接报错；稳一点的话，可以给机器 ID 预留额外位数，必要时用“备用机器 ID + 序列号膨胀”绕过。

号段模式则是每次从数据库取一批 ID 放到内存中，用完了再申请下一批。优点是简单、不依赖时钟；缺点是需要一次额外的 DB 交互，而且如果应用重启没消耗完有浪费。号段模式特别适合业务 ID 需要“方便人读”的场景。

7. 什么时候不该分库分表：几个反直觉的思考

前面聊了那么多方案和细节，最后想谈谈“克制”。我做了这么多年架构，一个很深的体会是：很多系统不是倒在了技术方案上，而是倒在了过度设计上。

你不该分库分表的情况，我列几个典型的：

数据量虽然大，但大多数是冷数据。比如日志表累计有 3 亿条，但业务只关心最近 3 个月的数据。这时候做“冷热分离 + 归档”比分库分表简单有效得多。
写入并发不高，瓶颈在读。优先考虑缓存（Redis）和读写分离。把热点数据放缓存里，读压力根本不压到 MySQL。
团队没有足够的运维能力。分库分表后，日常的备份恢复、扩容缩容、监控告警都变得更复杂。如果团队只有两三个人，建议优先依赖云数据库的弹性能力和托管服务。
分片之后的痛点已经远大于收益。跨分片的复杂查询、分布式事务、数据一致性校验，每一项都是持续的成本。如果你未来的业务需求大多是复杂的多维度报表，那关系型数据库或数仓工具可能更合适，而不是强行分库分表。

我还想强调一个很多人容易忽略的点：分库分表不是终极架构，它只是数据量增长到一定阶段后的一个中间态。更高阶的形态，其实是在“分布式存储中间件 + 多种存储引擎”的框架下去思考问题：MySQL 继续承担强一致的事务型数据，ES 负责大规模检索，冷数据放对象存储，报表进数仓。分库分表只是其中一环，而不是终点。

所以，如果你读完这一章后最深刻的感受是“原来分库分表这么麻烦、要慎重”，那我的目的就达到了。但如果你正准备做一个新系统，我反而建议多留一份心：在设计表结构的时候，就把分片键的维度考虑进去，比如订单表里冗余 user_id、merchant_id，这样即使将来分库分表，路由规则也不会太牵强。提前留好后路，比将来重构要省心太多。

8. 分库分表常见误区与排查心得

这一节我整理一下团队里新同学最容易出现的错误，以及我积累的排查思路，希望能帮你在自己动手做方案时少走弯路。

8.1 五个新手的常见误区

第一，选分片键时没考虑“范围查询会不会被杀掉”。选了 user_id 做分片键之后，运营后台每天都要按“下单时间”拉取全量订单报表，结果每个分片都要扫一遍，接口直接超时。处理方式就是前面提到的：核心联机查询走路由分片，报表分析走离线仓库或 ES。

第二，扩容时改路由规则，没有做平滑迁移。我看到不少同学直接把取模从% 4改成% 8，然后把旧数据一次性重刷到新库，结果迁移期间业务不可用。正确做法是双写、对账、灰度切流，哪怕多花几天时间，也千万别冒险一把梭。

第三，分片表忘了设计全局唯一键。单库自增主键在分库后一定会冲突，如果业务里用了order_no做唯一约束，一定要确保order_no的生成是全局唯一的，而不是每个库各自生成。

第四，没有保留“分片键说明文档”。半年后新同学接手的第一个问题一定是：“这个表是拿什么字段路由的？是取模还是范围？”如果你在代码注释、团队 Wiki 里都写清楚了路由规则、分片数、为什么选这个分片键，后面的人能省很多无谓的沟通成本。

第五，监控指标没有跟上。分库之后，数据库的实例从一个变成多个，慢查询、连接数、同步延迟这些监控如果还只覆盖原来那个库，出了问题很难定位。在每个分片上都部署好基础监控，是对自己负责。

8.2 线上问题排查的一些心得

分库分表后的排障也和单库不一样。我的习惯是三步走：

先看路由是否命中了预期分片。如果某条数据查不到，先用分片键手动计算一下它应该在哪个库、哪张表，然后直接去对应分片确认数据是否存在。很多“灵异现象”最后都是路由算错了。

再看分片之间的数据是否均衡。可以在各个分片上执行同一段统计 SQL，对比各分片的数据量。比如：

SELECT COUNT(*) FROM order_16; SELECT COUNT(*) FROM order_17; -- 多表汇总 SELECT 'order_0' AS tbl, COUNT(*) AS cnt FROM order_0 UNION ALL SELECT 'order_1', COUNT(*) FROM order_1;

如果发现某几个分片的数据量明显偏多，说明分片键的分布出了问题。常见原因是新旧用户号段不均匀，或者分片键取值本身有偏差。

最后看慢查询的日志是否聚集在某个分片。如果集中在某个分片，大概率是数据热点或连接池配置不合理，而不是 SQL 本身写得有问题。这时候需要先调整分片的容量和负载均衡，再去优化 SQL。

我举个例子：有一回线上的订单查询偶发超时，一开始都在排查 SQL 和索引，发现单条 SQL 执行很快，但偶尔会堵几十秒。最后定位下来，是因为 4 个分库中的 1 个库恰好承担了某个大商户 70% 的写入量，它的主从延迟升高，读请求走到从库时读到旧数据，走了多次重试才返回。处理方式是把大商户的流量单独拆出来，再对这个分库做扩容，问题立刻缓解。

9. 最后的实操建议：从评估到上线的分步走清单

如果你看完前面的内容，在脑子里已经有了“分库分表是个系统工程”的认知，那最后这份清单可以帮助你把想法落地到流程里。

第一步，量化现状。统计核心表的行数、行大小、日均新增量、读写 QPS、慢查询数量。量化数据是后续所有决策的基础。

第二步，评估五年内数据量级。结合业务增长，给出一个相对靠上的预估，然后用公式算出分片数。这里宁可稍微多点余量，也不能算得太紧，因为以后再扩分片的成本远高于一开始多分几片。

第三步，确定分片维度。找到一个“查询最高频且必须带上”的字段做分片键。如果核心查询有多个维度，考虑冗余表或索引表。

第四步，设计路由规则。优先采用“先分库、再分表”的双层路由，保证同一个分片键值的数据落在一个库内。编写清晰的路由工具类并配套单元测试。

第五步，实现数据迁移方案。旧数据全量同步、增量双写、数据校验、灰度切流，每一步都需要有明确的验证标准和回滚预案。

第六步，建立监控与告警。每个分片都要有独立的慢查询、错误日志、主从延迟、连接池水位监控。要有统一的 Dashboard，一眼看出各分片的负载差异。

最后一步，写文档。路由规则、分片键、分片数、迁移方案、踩坑记录，全部沉淀到团队文档里。后面接手的人会发自内心地感谢你。

关于分库分表的考量策略，我想说的核心就一句话：它是一项“不到万不得已不上，上了之后要全力以赴管理”的技术手段。做技术决策时，我们更多要衡量的是投入产出比、可运维性、团队能力，而不仅仅是数据量这个单一纬度。

如果你正在做订单、交易这类核心系统，提前把分片键的维度想清楚，绝对是值的。但也请你相信，把单库的索引、SQL、缓存做到极致，能解决大部分业务 90% 的读压力问题。分库分表是最后那张底牌，而打好这张牌的关键，是“想清楚策略”，不是“抄一个配置”。

MySQL分库分表策略解析：从评估到落地的完整指南