sql 分片扩容核心是“不停服、不丢数、不乱序”，需前置固化分片键与路由逻辑，采用一致性哈希 + 虚拟节点，通过双写→校验→灰度三阶段在线迁移，并同步演进元数据、连接池与监控。
SQL 分片扩容不是简单加节点，核心在于“不停服、不丢数、不乱序”——在线扩容必须兼顾数据一致性、业务连续性和迁移可控性。
分片键与路由逻辑必须前置固化
扩容前若未统一分片键（如 user_id、order_no）和路由算法（如取模、一致性哈希、范围分片），后续迁移将无法自动定位旧数据归属。一旦上线后修改分片规则，等于重做整套分库分表逻辑。
- 推荐使用 一致性哈希 + 虚拟节点 ，支持平滑增减物理分片，避免大规模数据搬移
- 所有读写 SQL 必须经由中间件（如 ShardingSphere、MyCat）或 SDK 路由，禁止应用直连具体库表
- 分片键字段需在业务层保证非空、稳定、低倾斜，避免热点分片
双写 + 校验 + 灰度：三阶段在线迁移法
停机迁移已不现实，主流方案是让新老分片并行服务，逐步切流，全程可回滚。
- 双写期 ：写请求同时落旧分片 + 新分片（按新规则路由），读仍走旧分片；开启全量历史数据迁移（用工具如 DataX、pt-archiver）
- 校验期 ：用比对工具（如 shardingsphere-scaling、自研 checksum 服务）逐分片核对新旧数据一致性，修复差异
- 灰度切流期 ：按用户 ID 段 / 流量比例逐步将读请求切至新分片，监控延迟、错误率、QPS 分布；确认稳定后关闭旧分片写入
元数据与连接治理不可缺位
扩容不是只动数据，中间件配置、应用连接池、监控告警、SQL 审计等都需同步演进。
- 分片拓扑变更必须通过配置中心（如 Nacos、Apollo）统一下发，禁止手动改配置文件
- 连接池（如 HikariCP）需预调大 maxLifetime 和 connection-timeout，避免新分片建连慢引发超时雪崩
- 监控要覆盖到“单分片 QPS/ 慢查 / 连接数”，不能只看全局指标；扩容后重点观察各分片负载是否均衡
小步快跑优于一步到位
一次性从 4 分片扩到 32 分片风险极高。建议按“2→4→8→16”节奏推进，每次扩容只增加 1 倍分片数，并预留 1~2 周观察期。
- 每次扩容前完成压测：验证新分片吞吐、主从同步延迟、跨分片事务（如有）表现
- 准备快速回滚方案：保留旧分片至少 72 小时，双写日志留存可追溯，回滚即切回旧路由 + 丢弃新分片写入
- DBA 与开发需共建分片健康看板，包含分片水位、热点 Key、拆分进度、校验状态等实时字段
不复杂但容易忽略：真正的难点不在 SQL 怎么写，而在整个链路的可观测性、可逆性和协同节奏。
