数据迁移的挑战与风险
做数据迁移这事，我干了好些年。说实话，每次接到迁移任务，心里都得先过一遍那三座大山——数据一致性、停机时间、性能影响。这三个东西像跷跷板，你压住一头，另一头就翘起来。
今天咱们就把这三个风险掰开揉碎了讲。你想想看，迁移失败最怕什么？不是跑得慢，而是数据对不上。那才是真正的大坑。
一、数据一致性——迁移的命门
数据一致性说白了就是“源库和目标库的数据长得一模一样”。但实际做起来，比想象的难多了。
核心难点：迁移过程中，源库还在继续写入。你刚拷贝完一条记录，下一秒它又被更新了。怎么保证最终两边一致？
我个人习惯把一致性拆成三个层次来看：
- 行级一致性——每条记录的所有字段都对应得上
- 关联一致性——外键、父子表、聚合数据的关系不破坏
- 时序一致性——迁移前后的业务状态在时间线上对齐
我记得有一次做银行账户系统的迁移。迁移过程中用户还在转账，我们用了一个双写方案——但业务代码有bug，导致一部分数据写了两次，另一部分漏了。最后对账差了三千多笔。嗯，那三天基本没合眼。
避坑指南：我曾经吃过一次大亏——只用行数校验判断一致性。后来发现有个表里50万行数据，行数一样，但其中3万行的金额字段因为编码问题被截断了。从那以后我坚持做“抽样全字段对比 + 哈希校验”。
常见的一致性保证手段，我整理了个表格：
| 方案 | 适用场景 | 风险点 |
|---|---|---|
| 全量快照 + 增量追 | 数据库支持快照读（如MySQL InnoDB） | 快照点之后的变更可能丢失，需补日志 |
| 基于日志的CDC | 高并发、准实时场景 | 日志解析延迟，断点续传复杂 |
| 双写 + 校验 | 业务可接受短暂停服 | 应用层改造大，事务一致性难保证 |
| ETL批量加锁 | 离线、低频率迁移 | 锁表时间长，影响在线业务 |
你看，没有银弹。每个方案都有取舍。我个人更倾向于“全量快照 + 增量日志回放”的组合，前提是数据库得支持一致快照。
二、停机时间——业务眼中的红线
业务方最关心的问题就一个：“要停多久？”
停机时间意味着直接收入损失、用户体验下降。我见过最急的case：某电商平台双十一前三天要求迁移数据库，业务只给了2小时的停机窗口。2小时要完成100亿条记录的迁移和校验，还得回滚预案就绪。你说紧不紧？
技巧：我建议把停机窗口拆成四个阶段——数据全量拷贝（可在线做）、增量追赶（可在线做）、全库锁定 + 最终同步（需要停服）、校验与切换（需要停服）。真正需要停服的只有后两段，时间可以压到15分钟以内。
停机时间的计算模型大概是这样的：
停机时间 ≈ 最终同步耗时 + 校验耗时 + 切换耗时
其中最终同步耗时取决于增量变更的速度。如果你的业务峰值每秒写入10万条，那就算CDC工具再快，也得留出足够的追赶时间。
避坑指南：我曾经以为增量追赶很快，结果上线当天发现源库有个跑批任务，每10分钟产生一次全表更新。CDC工具追了半小时才追上。从那以后，我要求运维至少提前一周监控源库的DML峰值和频率，作为停机时间估算的依据。
另外，注意“回滚”也是需要时间的。如果你切到目标库后发现问题要回源，可能又得经历一遍停服。所以，我习惯在迁移方案里明确写一条：切换后的前15分钟为观察期，只允许读流量，不允许写。这样一旦发现数据不对，回滚代价最小。
三、性能影响——别让迁移拖垮在线业务
性能影响往往是先被忽略、后成为上线拦路虎的问题。因为迁移工具本身也会消耗数据库资源：CPU、IO、网络带宽。
我归纳了三个最常见的性能风险：
- 源库压力增大——全量扫描导致Buffer Pool被冲，热点查询变慢
- 网络带宽挤占——大量数据传输影响正常业务请求
- 锁竞争加剧——批量操作带来行锁或表锁，引发死锁或超时
你会问：“那怎么控制影响？”
给你三个实用的控制手段：
- 限速与分片——不要一次全量拉取。我习惯每次读10000行就sleep 50ms，或者按主键范围分批。工具层面设置带宽阈值。
- 在从库上做全量拷贝——如果架构有只读从库，全量扫描走从库，主库只处理增量日志。
- 监控数据库活跃连接数和慢查询——一旦发现CPU超过70%或磁盘IO延迟超过10ms，立即暂停迁移任务。
我踩过的坑：有一次迁移MySQL，没有限制并发数。结果迁移工具开了32个线程同时扫表，直接把主库的IOPS打满，正常查询从3ms飙到200ms。好在是凌晨，业务影响不大。后来我写了个脚本，实时检测数据库的线程running数，超过阈值就自动降速。
再说一个容易被忽略的点——索引。全量插入目标库时，如果先建索引再插数据，插入速度会非常慢。我建议的策略是：目标库先去掉所有二级索引，只留主键，数据灌完后再重建索引。这个操作能快5～10倍。
好，三个风险讲完了。下面这张图可以帮你快速回顾它们之间的关系：
看到这张图，你可能会想：有没有一个统一的方法能把这三个风险都降下来？答案是：有，但需要组合拳。比如用在线迁移工具（如gh-ost）可以在线做DDL和数据拷贝，配合CDC追变更，再通过灰度切换把停机时间降到秒级。但代价是架构复杂度上升，性能开销也会多10%左右。
归根到底，数据迁移没有完美的方案。你得根据自己的业务容忍度来选。我个人的原则是：宁可慢一点、停一会，也别数据对不上。因为数据一致性问题往往要等上线几周后才会暴露，那时候修复成本高得吓人。