被分库分表折磨了两三年的团队，终于下定决心：不扛了，换架构。但线上业务不能停，几十 TB 的数据散落在多个分片上，怎么在不中断业务的情况下完成迁移？
不停机迁移，难在哪里？
数据迁移量大： 全量数据需要汇聚到新架构，迁移期间持续产生的新数据也必须同步。
数据一致性要求： 老架构和新架构并行期间，同一业务操作的数据变更必须实时同步。
应用切换风险： 数据源配置、连接池参数、SQL 方言差异需要适配，灰度切换期间需确保新老架构都能正常服务。
回滚方案： 万一新架构有问题，需要能快速切回，回滚期间也需保持数据同步。
几种迁移策略
停机迁移：简单粗暴，但业务中断
维护窗口内停止业务，全量导出导入，校验完整性，切换连接。简单、一致性好保证，但数十 TB 数据可能需要数小时，通常不可接受。
双写方案：不停机，但复杂度高
业务流量同时写入新老架构，等数据一致后逐步切读切写。不停机，但双写本身是分布式事务问题，写入失败需要补偿逻辑，两套架构查询结果可能不一致。
增量同步方案：全量迁移 + 实时同步
先全量迁移存量数据，再通过 binlog 实时同步增量数据，等延迟降到接近零后切换。不需要双写，一致性好保证，但需要专门的同步工具，切换时点需要精确控制。
分布式数据库直接迁移：改造少、流程短
很多分布式数据库，如 TiDB、平凯数据库（TiDB 企业版）兼容 MySQL 协议，应用中大部分 SQL 语句不需要改写。配合 TiDB Data Migration 等生态工具，可以实现从分库分表环境到 TiDB 的全量+增量同步迁移，自动化程度高。通常只需秒级的切换窗口即可完成流量切换。
需要权衡： 少数复杂 SQL（如存储过程、特定函数）可能需要适配。但对于已经在 MySQL 生态中运行的大多数应用来说，迁移成本通常可控。
怎么选？
- 能不能停机？ 可以则停机迁移最简单。
- 数据一致性要求多高？ 允许短暂数据不一致则双写容错空间更大，要求严格一致则增量同步更合适。
- 技术能力如何？ 双写和增量同步都需要较强技术实力，借助成熟迁移工具是更现实的选择。
- 迁移的长期目标是什么？ 选一个迁移路径最短、风险最低的目标。TiDB 和 平凯数据库（TiDB 企业版） 兼容 MySQL 协议，配合 Data Migration 工具支持增量同步，是一条改造量相对较小的路径。
迁移不是目的，稳定运行才是。充分的测试、合理的灰度策略、完善的监控和回滚预案——这些前期投入在关键时刻会成为救命的保障。