第1章 数据迁移概述：定义、挑战与典型场景
1.1 到底什么是数据迁移？
数据迁移，说白了就是把你系统里的数据，从一个地方挪到另一个地方。听起来很简单对吧？但做起来，远比想象中复杂。
我最早接触数据迁移那会儿，以为就是个“复制粘贴”的活儿。结果第一次上生产环境，就把某银行的交易流水迁丢了三千条。嗯，从那以后我再也不敢小看这事了。
严格来说，数据迁移是：
- 将数据从源系统（旧库、旧文件、旧接口）
- 经过抽取、清洗、转换、校验
- 完整、准确、无损地写入目标系统
- 并保证业务的连续性和数据一致性
核心要点：数据迁移不是移动数据本身，而是移动数据的价值。如果迁移后数据对不上、用不了，那跟没迁一样。
1.2 迁移工作中的三大挑战
这些年我参与了不下三十次数据迁移项目，从几十GB的小库到几十TB的金融核心库都有。总结下来，最头疼的是下面三个问题：
挑战一：停机窗口太短
业务方通常只给你一个周末，甚至一个凌晨。你想想看，几百TB的数据要在几小时内迁完，还要校验，还要回滚预案——时间永远不够用。
我在项目中遇到过最极端的一次，留给我们的就4个小时。最后两小时还因为网络抖动断了三次。那次我学会了一个道理：永远不要指望业务方给你足够的时间。
挑战二：数据一致性难以保证
迁移过程中，源系统还在写入新数据。你刚迁走A表，B表又更新了关联字段。对不上，怎么办？
我曾经在一个电商大促后的数据迁移里，就因为订单表和支付表的“时差”，导致2000多笔订单状态错乱。后来我们被迫用了整整一轮全量对账才修复。所以我现在做迁移，一致性校验必须做到字段级。
挑战三：性能与资源的平衡
迁移工具跑得快，源库IO打满，业务跟着响应变慢；跑得慢，又赶不上窗口。这个平衡点，很难找。
| 挑战 | 典型表现 | 我常用的应对策略 |
|---|---|---|
| 停机窗口 | 时间不够，任务超时 | 增量+全量分批、并行迁移 |
| 数据一致性 | 记录对不上、关联断裂 | 字段级校验、快照对比 |
| 性能与资源 | IO打满、业务抖动 | 限速、错峰、读写分离 |
曾经有个教训：某次迁移我们为了赶时间，把全量抽取的并发数调到了32。结果源库的IO直接飙到100%，业务系统从秒级响应变成了分钟级。从那以后，我规定所有迁移任务必须带限速配置，哪怕慢一点，也不能影响线上。
1.3 数据迁移的典型场景
我归纳了一下，常见的场景基本逃不出这几类：
- 数据库迁移：从MySQL迁到PostgreSQL，或者从Oracle迁到分布式数据库。这是最经典、也是最坑最多的场景。
- 上云/下云迁移：从自建机房迁到公有云，或者反过来。网络延迟、带宽瓶颈、安全策略都是拦路虎。
- 同构/异构迁移：同构比如MySQL 5.7迁到MySQL 8.0，相对容易；异构比如SQL Server迁到MongoDB，那就要面对数据类型映射、存储结构变化等问题。
我个人习惯把场景分成两类：“可割接” 和 “难割接”。可割接的意思是，允许有一小段停机时间；难割接则是业务7x24小时不能停，比如支付系统、交易系统。后者的SDK接口适配和回滚策略，就得做得特别精细。
一个小技巧：判断迁移场景的复杂程度，可以看“源-目标”之间的数据模型差异有多大。差异越大，SDK接口适配的改动量就越大，回滚的难度也越高。我一般在项目启动阶段就会做个“数据模型对比检查表”，提前把坑列出来。
1.4 本章知识体系总览
下面这张图，把数据迁移的核心脉络画出来了。你仔细看，就能理解为什么我们需要后面那么多章节来聊SDK接口适配和回滚。
1.5 为什么SDK接口适配这么关键？
你可能会问：迁移数据就迁移数据，关SDK接口什么事？
其实关系大了。现在的业务系统，几乎都是通过SDK封装的数据访问层来读写数据的。你换了底层存储，SDK不改，业务代码根本跑不动。
我在做一个金融项目时，老系统用JDBC直连Oracle，新系统要求走统一的分布式数据服务SDK。表面看是“换库”，实际上业务代码里所有SQL调用都要改成SDK接口。那滋味，真是一行一行改出来的。
所以这门课的核心，就是帮你搞定两件事：
- 怎么设计SDK适配方案——让业务代码改动最小，迁移平滑
- 怎么实现可回滚——万一迁出问题，能快速恢复，不背锅
一个经验：做SDK适配时，我倾向于先写一个“双写”代码——数据同时写旧库和新库，跑一段时间观察一致性和性能。确认没问题了，再切流量。这个过程虽然慢，但安全。急的事情，往往容易出错。