迁移策略选择：全量、增量、双写

说实话，每次做数据迁移，最让人头疼的不是技术细节，而是选策略。选错了，后面全是坑。我个人习惯先把业务场景拉出来，停机时间能忍多久？数据量多大？一致性能不能有窗口？搞清楚这三条，策略基本就定了。下面我把三种主流策略掰开揉碎了讲，每个都带点我自己踩过的雷。

全量迁移 —— 简单粗暴，但别用错地方

全量迁移就是一次性把源库的所有数据复制到目标库。听起来很痛快对吧？我有一次帮一个电商客户做订单历史库迁移，就是用的全量。当时想，啊，反正历史数据不更新，直接全量过去就行。结果呢？3TB 的数据，迁了整整12个小时，中间还断了一次连接。最后只好加班重跑。

所以全量迁移不是不能用，而是要有前提：

• 业务允许一段较长的停机窗口（通常几小时到一晚上）。
• 数据总量可控，单表尽量不要超过 500GB（高 IO 环境可以放宽）。
• 迁移期间源表不被写入（只读或阻塞写）。

它的最大优点是逻辑简单，甚至不用中间件，一条 SELECT INTO 或者 mysqldump 就能跑。但缺点也明显：数据量大时耗时极长，而且一旦失败可能得重头再来。我后来学乖了，全量迁移前一定先做一次数据采样估算——捞 10 万行数据，算出去掉网络开销的纯传输速率，再倒推总时间。如果算出来超过业务能接受的停机窗口，就老老实实上增量或双写。

增量迁移 —— 不停机也能迁

增量迁移解决的就是“不能停服务”的问题。它先做一次全量基线，然后持续同步源库新产生的变更。说白了，就是一边跑着业务，一边偷偷把数据搬过去。

增量迁移的核心是“变化数据捕获”（CDC）。我常用的方案有两类：

• 基于数据库日志：比如 MySQL 的 binlog、PostgreSQL 的 WAL。又准又实时，但需要解析日志的 SDK 去做转换。
• 基于时间戳或版本号：表里得有 updated_at 或 version 字段。无法捕捉删除操作，除非额外做软删除。

增量迁移最大的好处是业务几乎无感。但我跟你说，它最烦人的地方是「延迟」。我记得有一次做跨机房增量同步，网络抖动导致 binlog 消费延迟了十几分钟。业务方发现用户改了密码，登入时还是旧密码（读的是目标库），差点投诉。后来我强制加了「读源库降级」策略——如果增量延迟超过 5 秒，流量自动切回源库。

双写模式 —— 最稳，但改造代价最大

双写，说白了就是数据同时写入源库和目标库。一个写请求进来，SDK 拆成两条写路径：一条写旧库，一条写新库。我参与过一个金融风控系统迁移，因为数据一致性要求极高（不能有任何窗口），最终就选的双写模式。

双写最核心的问题是：怎么保证两边都写成功？如果源库写成功、目标库写失败，怎么补偿？你可能想到分布式事务，但那太重了。我一般用「异步对账+定时补偿」的思路：

1. 写操作在 SDK 里先写源库，成功后把变更事件写入本地消息表（或者 Redis 延迟队列）。
2. 后台线程异步回放事件到目标库。
3. 每分钟跑一次对账脚本，对比两边关键字段（比如金额、状态），发现不一致就挂告警并自动重放。

这种方式能让双写达到「最终强一致」，而且对业务代码侵入相对小。但我也得坦白讲，双写模式对 SDK 的改造量最大。你需要在 SDK 里增加一个「双写开关」和「写入策略」——是同步写还是异步写？是强依赖源库成功后再写目标库，还是并发写入？这些决策直接影响业务延迟。

你可能会想，那什么时候该用双写？我个人判断标准就两条：

• 业务完全不能接受停服（哪怕 10 秒）。
• 数据一致性不能有任何时间窗口（比如金融交易、用户余额）。

两条都满足，那就别纠结，老老实实上双写。不过你要有心理准备：双写模式的 SDK 改造工期至少比增量多一倍。我记得有个项目，光设计写入补偿逻辑就花了两周。

三种策略怎么选？一张图看清

下面这张决策流程图，是我每次做迁移规划必画的。你照着走一遍，基本不会错。

嗯，最后补一句心里话：没有完美的策略，只有最适合你当前业务的妥协。全量快但停机长，增量灵活但延迟烦，双写稳但改得痛。我刚才画那张图，其实就是我这些年实践下来的“决策速查表”。下次接到迁移需求，你打开这个流程图走一遍，选型时间能从半天缩到十分钟。