月度归档：2026年7月 (56)
分片治理：水位、倾斜与再平衡
拆完不是终点，是另一场长期管理的开始：每个分片的容量水位涨到哪儿了？数据是不是悄悄倾斜了？三年后的容量今天规划够不够？分片系统的健康不靠某次重构，靠一套日日看、月月盘的治理机制。
冷热分离与归档：让主表保持轻盈
互联网数据有个铁律：绝大多数查询只发生在最近的数据上。把两年前的订单请出主表，两亿行立刻瘦到三千万——索引变矮、缓存变热、DDL 变快。归档不是把数据一删了之，冷库选型、限速批次、可回捞的查询入口，一样都不能少。
在线 DDL：分片环境的表结构变更
单表改一次结构要拷表八小时，分片之后变成三十二张表改三十二次——好消息是每张都小了，坏消息是协调成本翻了几十倍。gh-ost 那套在线改表在分片环境怎么排兵布阵、新结构上线前怎么保证新旧代码兼容，这一篇给出演练清单。
数据迁移（下）：校验、切流与回滚预案
双写追平只是「看起来一致」，校验通过才算「证明一致」——行数核对、分块 checksum、抽样比对三道关。之后按用户白名单灰度切流，先读后写，每一步都留着回滚的门。迁移工程的下半场，全是流程与纪律，没有算法。
数据迁移（上）：双写方案的全貌
几亿行的库没法一夜搬完，停机迁移窗口又批不下来——能走的路只剩一条：老库继续服役，新库并行建设，双写保同步，校验合格再切流。四阶段迁移框架是分库分表工程里的重头戏，本篇先搭出全貌：存量怎么搬、增量怎么追、双写怎么写。
扩容：成倍扩容与预分片
取模分片的账迟早要还：模数从 32 改到 64，几乎所有数据的归属都变了，全量重新分布。翻倍扩容法让搬家量降到一半，预分片则更进一步——1024 个槽从第一天起固定不动，扩容只改槽到库的映射。设计期为未来的自己铺路，扩容那天才不手抖。
分片友好的主键：ID 里埋下路由基因
分库之后，全表共享的自增主键第一个阵亡——每个分片各自从 1 数起，撞车只是时间问题。全局唯一、趋势递增、还能算出路由，分片主键的三重身份缺一不可；基因法把分片键的哈希直接埋进 ID，让订单号自己会走路。
分片后的事务：本地事务的边界与柔性方案
拆库之前一个事务包住所有写，拆库之后事务的边界画在了分片线上——带分片键的写落单库，事务照旧；跨片的写被中间件拆成多个本地事务，失败就是部分提交。最好的解法是设计期就把事务锁进单库，剩下的用柔性方案兜底。
跨分片查询（下）：分页、JOIN 与广播表
跨片分页是归并账本里最贵的一页：取第 100 页的 10 条，中间件要向所有分片要回前 1000 条——翻得越深，浪费越大。JOIN 则在分片下全面受限：同片能连，跨片靠冗余。绑定表与广播表，是把 JOIN 从灾难变回日常的两件工具。