SaaS系统在发展过程中，数据库迁移几乎不可避免。可能是从单库迁移到分库分表，可能是从自建MySQL迁移到云数据库，也可能是为了支持多租户隔离而从共享表迁移到独立Schema。无论哪种场景，"停机迁移"都是不可接受的------跨境业务覆盖全球时区，任何时候都有用户在访问。Taocarts在实践中经历了从单库到多租户分库的迁移，全程零停机。
迁移的核心挑战
数据库迁移最难的不是"搬数据"，而是"不停业务"。传统做法是停服、导出数据、导入新库、切流量------但跨境SaaS停服几分钟就可能造成大量订单丢失和用户投诉。零停机迁移的核心思路是：新旧库并行运行一段时间，等数据完全一致后再切流量-。
双写模式保障业务连续性
最成熟的零停机迁移方案是"双写+校验+切换"三阶段-。
第一阶段：双写。应用代码改造为同时写入新旧两个库，但读请求仍然走旧库。这个阶段要验证新库的写入性能和数据格式是否正确-。
第二阶段：存量数据迁移与一致性校验。用工具把旧库的历史数据全量迁移到新库-。迁移过程中新数据还在不断写入，所以还要开启增量同步------通过解析旧库的binlog，把变更实时同步到新库-。迁移完成后，运行数据校验脚本对比新旧库的关键数据，发现不一致就及时修复-。
第三阶段：流量切换。确认数据一致后，把读流量也从旧库切换到新库-。切换不是一次性全部切过去------先切5%的流量观察几天，没问题再逐步扩大到全量-。万一新库有问题，可以快速切回旧库。
多租户场景的特殊处理
多租户系统的迁移比单租户更复杂。不同租户的数据量差异可能很大------大客户可能有几百万条订单，小客户可能只有几千条-。如果所有租户用同样的迁移策略，大客户的数据迁移可能耗时数小时，拖慢整体进度-。解决方案是按租户分批次迁移------先迁移数据量小、业务影响小的租户，积累经验后再处理大租户-。
另一个问题是租户间的数据倾斜。共享表方案中，个别大租户的数据可能占表的绝大部分。迁移时需要对大租户单独做分区迁移，避免全表扫描影响线上业务-。
切换瞬间的短暂延迟
即使准备再充分，流量切换的瞬间也可能出现短暂的延迟增加。实践中，切换时数据库连接池需要重建、缓存需要预热，这些操作可能导致几十到几百毫秒的延迟抖动-。应对方案是在切换前先预热新库的连接和缓存，把影响降到最低。
几个落地的建议
迁移之前，先在测试环境完整跑一遍流程------包括双写、数据迁移、校验、切换、回滚，每一步都要验证-。迁移过程中要全程监控新旧库的延迟和数据一致性指标，一旦出现异常立即暂停。最后，永远准备一份回滚方案------如果切流量后发现新库有问题，能在几分钟内切回旧库-。