分库分表学习路线

先判断「要不要分」，再决定「怎么分」，最后才是「用什么中间件」。顺序反了，很容易为了工具而分片。

适用版本：ShardingSphere 5.5.x；配置格式随版本变化，以官方文档为准。

篇目

编号	篇目	回答的问题
01	分片策略与扩容方案	什么时候不该分片、分片键怎么选、扩容怎么迁
02	ShardingSphere 深度配置	JDBC/Proxy 怎么选、5.5.x 配置怎么写、有哪些 SQL 边界
99	生产检查清单	上线前、运行中、故障时逐条核对

推荐顺序

先读 01 的前两节：判断要不要分、分片键怎么选
  → 再读 01 的扩容部分：确认未来 2–3 年怎么加机器
  → 最后读 02：把选型落到配置和 SQL 兼容性
  → 上线前过 99

为什么这样排

分库分表不是「数据多了就做」的标准动作。单表几千万行，B+ 树仍然只有三四层；真正先撑不住的往往是单机 IOPS、写入吞吐、大表 DDL、备份恢复时间，而不是索引高度。

所以顺序是：

1. 先排除不该分的场景：能加索引、加从库、加缓存、归档历史数据解决的，优先做这些。
2. 再定分片键：它决定 80% 的查询能不能精确路由，也决定扩容时迁多少数据。
3. 再定扩容路径：取模、范围、一致性哈希、虚拟槽的迁移代价完全不同，要和分片算法一起定。
4. 最后选中间件：ShardingSphere-JDBC 还是 Proxy，取决于语言栈、部署形态和 SQL 复杂度。

怎么用

• 正在评估「要不要分」：01 的「什么时候不该分片」和「分片键怎么选」。
• 已经决定要分：01 的算法对比与扩容方案，02 的配置。
• 遇到跨片 JOIN、深分页、分布式事务：02 的「SQL 兼容性」和「分布式事务」。
• 上线/排障：99 检查清单，再回到正文查原因。

按问题找篇目

现象或问题	先看
单表多大才需要分	01
分片键选 user_id 还是 order_id	01
取模扩容要迁多少数据	01
一致性哈希到底迁哪些数据	01
跨片 JOIN 结果不对	02
深分页超时	01、02
配置加载成功但路由不对	02
上线前不知道检查什么	99

前置知识与读完目标

读之前只需要熟悉 MySQL 的单表索引、事务和 Binlog 基本概念（对应 03_MySQL 的 01、04、05 篇）。读完之后应能回答：

1. 为什么「数据量大」不是分片的充分理由。
2. 分片键如何同时决定路由命中率和扩容迁移量。
3. 取模、一致性哈希、虚拟槽在扩容时各迁多少数据。
4. 哪些 SQL 在分片后会变慢或结果不正确。