二十篇的三段旅程
系列收官，照例把旅程收拢。第一段（1-5 篇）：决策与设计——从一次改不动的 DDL 认清单表天花板，三招顶格优化守住「能不拆就不拆」的底线，垂直拆理顺业务边界，三种水平刀法各就其位，分片键作为终身决策反复锤炼。第二段（6-12 篇）：架构与落地——路由的三种落法，ShardingSphere 把方案变成配置，五步流水线看穿中间件，跨片聚合、分页、JOIN 的归并账本逐页算清，事务用设计锁进单片，主键埋进路由基因。第三段（13-20 篇）：演进与治理——翻倍扩容与预分片铺好未来的路，四阶段迁移完成安全交割，在线 DDL、归档瘦身、水位治理支撑长期运转，七个事故把执行漏洞照个通透。
一张作战地图
如果整个系列只能带走一页纸，是这张决策流：第一步——索引、归档、读写分离顶格打完，还撑不住才谈拆（第 2、17 篇）；第二步——垂直拆理顺业务边界，再做水平拆（第 3-4 篇）；第三步——用查询分布数据选分片键，基因法补多维度查询（第 5 篇）；第四步——Hash 加预分片留扩容后路，1024 槽映射从第一天起固定（第 4、13 篇）；第五步——绑定表锁 JOIN、广播表放维表、跨片 JOIN 用异构替代（第 10 篇）；第六步——事务能单片就单片，跨片走柔性加对账（第 11 篇）；第七步——迁移走存量、双写、校验、灰度四阶段，老库下线才算终点（第 14-15 篇）；第八步——水位、倾斜、容量进例会，治理无终点（第 18 篇）。
面试题里的老朋友
这套知识也是分库分表面试的全部高频区，串一遍：「什么时候分库分表？」——顶格优化之后仍顶不住写瓶颈或热数据规模，参考线加证据说话；「分片键怎么选？」——高频维度做键、基因法补洞、冗余或异构兜底；「扩容怎么办？」——翻倍扩容的数学性质，或预分片的槽位映射；「迁移怎么保证不丢数据？」——先启双写再搬存量、三道校验、灰度切流、老库保留观察期；「跨片查询怎么办？」——能路由不广播、能异步不实时、能预计算不算细账。答案的骨架都在各自篇章，价值在于把机制讲成取舍。
与整个体系的位置
把这个系列放进更大的地图里看：MySQL 系列打的是「单库内部的仗」——索引、事务、复制、调优；本系列打的是「数据横向扩张的仗」——拆分、路由、迁移、治理；发号、事务这些深水区各有自己的坑，值得更专门的展开——事实上后面已有系列在排队讲它们。缓存、限流熔断这些系列，则是在数据层之上解决流量层的仗。单库优化、横向拆分、流量治理——三条战线合成一套完整的服务端作战体系。
写在最后
回头看开篇那次的八小时 DDL，它真正的价值不是逼出了分库分表，而是逼团队第一次认真回答了一串问题：数据到底为谁而存、查询到底长什么样、容量到底会涨到哪。分库分表只是这些问题的答案之一——它逼你完成的业务梳理和数据治理，比分片本身更值钱。系列完结，感谢一路追更，地图交到你手上，路上见。
评论 (0)