拆前穷尽：别急着分库分表
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 4 · 分库分表 · 第 22/49 篇 · 🚧 占位待学
上一篇：《MQ 选型：RocketMQ、Kafka 与 RabbitMQ 的分野》
下一篇：《垂直拆分：按业务与按读写特征切》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 4 · 单元 4.1
一、本文要解决的问题
数据库一慢就说「上分库分表」，就像发烧就说「换心脏」。分库分表是最后的大招——它杀死 join、杀死跨库事务、让运维复杂度上一个数量级。这一篇先学「大招之前必须穷尽的五件事」，它们能解决 90% 的「慢」。
二、知识点清单
- 优化阶梯：索引与 SQL 优化 → 读写分离 → 缓存 → 归档冷数据 → 分库分表，每一级解决什么量级的问题
- 拆分阈值经验值：单表行数（千万级考虑、亿级必须）、单库写入 TPS、磁盘与连接——阈值是结果不是原因
- 慢 SQL 治理：explain 全流程、索引设计原则、深分页的几种优化（为跨分片分页埋线）
- 冷热分离与归档：时间分区表、历史表搬离、归档任务的套路
- 分库分表的代价预告：跨库 join / 事务 / 分页 / 聚合 / 运维（扩容迁移），每一项都要付
三、动手实验（学习时必须真跑）
- 造 5000 万行大表（脚本灌数据），对比三种查询耗时：无索引 → 加索引 → 按时间归档后热表只剩 500 万
- 记录深分页实验：limit 100 万 offset 的耗时与优化（游标 / 延迟关联）
- 写一份「拆前检查清单」：给自己的示例系统订单表逐项打勾
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。