分库分表数据迁移需兼顾一致性、可控切流与低业务影响，核心采用双写/影子库、分批校验、灰度流量等组合策略，并严格保障全链路校验、可逆回滚及渐进切流。
分库分表后的数据迁移不是简单导出导入，核心在于保持一致性、可控切流、最小化业务影响。直接用 mysqldump 或逻辑复制容易丢数据、锁表久、无法回滚，必须设计带校验、分批、双写/影子库、流量灰度的组合方案。
明确迁移类型再选路径
不同场景对应不同策略：
- 同构迁移（如 MySQL→MySQL，分片规则不变）：优先用双写+数据对比+平滑切流。应用层同时写旧库和新库，通过数据校验工具（如 pt-table-checksum + pt-table-sync 或自研比对服务）定期核对差异，修复后逐步切读流量，最后切写。
- 异构迁移（如单库→分库分表，或分片规则变更）：需全量+增量同步+映射转换。先用 DataX、Canal + 自定义 processor 或 Flink CDC 抽取旧库全量数据，按新分片键重分布写入；再捕获 binlog 增量，实时解析并路由到目标分片；过程中注意主键冲突、唯一索引、时间字段精度等转换细节。
- 在线扩缩容（如从 4 分片扩到 8 分片）：采用一致性哈希重分布 + 流量拦截 + 补偿任务。不中断服务，通过代理层（如 ShardingSphere-Proxy 或自研网关）识别未迁移分片的请求，临时拦截并落库待处理；后台启动迁移任务将旧分片数据按新哈希规则拆分写入；完成后释放拦截，用校验工具扫尾。
关键环节必须做三件事
无论哪种方案，以下三点缺一不可：
- 全链路数据校验：不能只比行数。要按分片粒度抽样比对 checksum（如 CRC32(字段拼接)），重点校验金额、状态、时间类字段；生产环境建议保留 7 天校验日志，支持随时追溯。
- 可逆与快速回滚能力：旧库数据至少保留 1 周只读；新库开启写保护开关（如配置中心控制是否允许写入）；双写阶段任一库失败时，自动降级为单写并告警，避免脏写。
- 业务低峰期 + 渐进式切流：首次切读从 1% 流量开始，观察监控（QPS、延迟、错误率、慢查）15 分钟无异常再加；写流量最后切，且首小时限流 50%，防止突发压力压垮新库。
避开高频踩坑点
这些细节常被忽略，却极易引发线上事故：
- 分片键变更时，历史数据重分片必须重算路由，不能简单按当前值 hash——例如原用 user_id 分片，现改用 tenant_id + user_id 联合分片，老数据需补全 tenant_id 后再路由。
- 使用 Canal 等中间件时，务必开启 GTID 并校验 position 连续性，避免主从切换导致 binlog 断点，造成增量丢失。
- 跨库 join 查询在迁移后失效，提前收敛 SQL：把关联逻辑提到应用层，或用宽表/ES 做聚合查询，禁止在新架构中保留多库 join。
- 事务一致性难保障？拆分分布式事务为本地事务 + 最终一致：例如转账场景，先扣 A 库余额，发 MQ 通知 B 库入账，B 库消费失败则走定时补偿。
工具链推荐（轻量实用为主）
不追求大而全，够用、易调试、可监控最重要：
- 全量迁移：DataX（插件丰富）、mydumper（比 mysqldump 快 3–5 倍，支持多线程导出）
- 增量同步：Canal（阿里开源，生态成熟）、Flink CDC（适合复杂 ETL 场景）
- 数据校验：pt-table-checksum（Percona Toolkit）、shardingsphere-scaling（适配 ShardingSphere 生态）
- 流量管控：ShardingSphere-Proxy（内置读写分离+影子库）、自研网关 + Apollo 配置开关
迁移本质是工程协同问题，技术方案要匹配团队运维能力和业务容忍度。上线前务必做全链路压测和故障注入演练（比如模拟新库宕机、网络延迟、校验失败），验证回滚路径真实可用。不复杂但容易忽略。
