分库分表实战：拆分时机、路由策略与扩容路径

先问要不要拆，再问怎么拆

分库分表是「用架构复杂度换性能」的手术，能不做就不做。触发拆分的真实信号只有三个：单表数据量导致查询与 DDL 变慢（B+ 树层高增加、索引膨胀，经验值 5000 万行级）、单实例写入瓶颈（IOPS/连接数打满，读可以靠从库扛，写不能）、多租户隔离需求（合规要求或故障隔离）。没有这些信号时，优先用索引优化、读写分离、归档冷数据三板斧续命。一、垂直拆分与水平拆分

1. 垂直拆分：按业务域把不同表拆到不同库（订单库、用户库），或把大字段拆出主表——实施简单、边界清晰，是水平拆分的前置动作；
2. 水平拆分：同一张表按分片键拆到多个库表。核心决策是分片键：必须覆盖该表 80% 以上的查询条件——订单表用 user_id 分片，则「按订单号查询」就要路由两次或冗余映射表；分片键选错是分库分表事故的最大来源。

二、路由策略三选一

1. 哈希取模：数据分布均匀，但扩容要迁移大量数据（取模基数变化时几乎全量重分布）；
2. 范围分片：按时间或 ID 区间，扩容只需新增区间、历史数据不动——时间序列业务（订单、日志）首选，但热点问题明显（最新分片承担全部写入）；
3. 一致性哈希/查表法：虚拟节点让扩容迁移量降到 1/N，查表法（路由表存分片映射）最灵活但要维护路由服务。主流实践：基因法——把 user_id 的哈希低位嵌进订单号，让订单号天然携带分片信息，两键查询都免二次路由。

三、绕不过去的四个问题

1. 跨分片查询：非分片键查询要么广播全部分片（聚合慢），要么走异构索引——把数据按另一个维度再写一份（ES/宽表/CQRS 读模型），这是分库分表的标准代价；
2. 分布式事务：跨分片写入放弃强一致，用本地消息表/事务消息达成最终一致（详见最终一致性方案），资金场景用对账兜底；
3. 全局唯一 ID：自增主键失效，用雪花算法或号段模式（Leaf），注意时钟回拨与 workerId 分配；
4. DDL 变更：几百张分表的 Schema 变更是工程难题，用工具（gh-ost 类原理的分表版）批量执行并支持断点续跑。

四、扩容与双写迁移

在线扩容的标准动作是双写迁移：新旧分片同时写入 → 历史数据全量搬迁 → 校验对账 → 灰度切读 → 下线旧分片。全程可回滚，风险最大的是「双写不一致」——对账任务必须在切读之前跑干净。扩容规划一次到位（预估 3~5 年数据量），避免一年一拆。

分库分表的本质：把「一台数据库扛所有」变成「一群数据库各管一段」，代价是失去跨分片的事务与查询能力。拆之前想清楚用什么补偿这些失去的能力，拆的时候分片键决定一切——这两点想明白了，分库分表就从玄学变成了工程。