分库分表

用途：判断单表/单库是否已到极限，以及如何设计分片方案

什么时候真的需要

先排除更便宜的方案：索引与 SQL 优化、读写分离、缓存、冷热数据分层、归档、垂直拆分（按业务拆库）、单表分区。分片是最后手段，因为它把复杂度转移给应用与运维。

经验阈值（非硬规则，取决于行宽与访问模式）：单表数千万行或单表数百 GB、且优化后仍无法满足延迟目标时考虑水平分片。

常见策略：哈希取模（均匀，扩容需迁移）、一致性哈希（扩容迁移量小）、范围分片（易热点但利于区间查询）、基因法（把主表分片位嵌入二级表 ID，使二级表可按同键路由）。

形态	代表	特点
客户端 SDK	ShardingSphere-JDBC	无额外网络跳，语言绑定
独立代理	ShardingSphere-Proxy、MyCat、Vitess	多语言接入、集中治理，多一跳与运维对象
云原生分布式数据库	TiDB、OceanBase、CockroachDB、PolarDB-X	对应用近似单库，代价是新的运维与成本模型

选型要点：是否接受额外组件故障域、扩容是否需要在线再平衡、SQL 兼容度、分布式事务与全局索引能力、可观测性。

双写（新旧同时写）→ 历史回填 → 双向校验（对账）→ 灰度切读 → 停旧写。每一步都要有回滚开关，且校验必须覆盖行数与关键字段。