分库分表是把单库问题换成分布式数据问题。只有当索引、归档、读副本、垂直拆分和硬件扩展仍不能满足有量化证据的容量目标时，才值得承担它的长期复杂度。
Table of contents
Open Table of contents
先问是否真的需要分片
收集表与索引增长、写入 QPS、热点、查询分布、维护窗口和未来两年预测。很多“亿级表”仍能通过正确索引、冷热分层和按时间归档稳定运行；很多小表却因热点账户在单行上竞争而需要重新建模。
分片键决定未来成本
好的分片键让大多数请求只访问一个分片，并让写入分布均匀。按 user_id 分片适合用户内订单查询，但全局订单号、跨用户报表和超级大客户会带来额外问题。
ShardRouter.java下载演示确定性路由：同一用户总去同一分片。真实系统还需要路由版本、扩容映射、全局 ID、批量路由与故障策略。简单取模在扩容时会移动大量键，不能直接当完整方案。
跨片代价要显式暴露
跨片 Join、全局唯一、排序分页、聚合和事务都变难。常见处理是按业务聚合边界重塑查询，把分析数据同步到 OLAP 系统，或用 Saga/Outbox 接受受控的最终一致性。不要在中间件里隐藏无限制全片扫描。
在线迁移的安全主线
建新结构 → 全量回填 → 捕获增量 → 持续校验
→ 灰度读新 → 切写 → 观察 → 停旧链路每步都要幂等、限流、有进度点和回滚条件。双写不能只看“两边调用都成功”，还要处理部分失败和顺序；可用 Outbox 或变更数据捕获建立可重放增量。校验包括数量、分桶校验和、关键字段与业务不变量。
历史归档也属于迁移：定义保留期、查询入口、删除证明和法律保留。归档成功且可读取后，才分批删除热库数据并观察复制和 Undo 压力。
下一步
继续阅读06-18 JDBC、连接池、JPA/Hibernate 与 Spring Data，比较 Java 持久化技术的抽象层次。