你手头有个用了好几年的数据库，每天跑着几百个业务，数据量已经堆到几十TB。突然老板说，下个月要把整个系统搬到新平台上去。你心里咯噔一下——这活儿听着简单，做起来全是坑。我见过太多团队栽在这件事上。数据迁移听起来像是拷贝粘贴，但数据库这东西，牵一发动全身。表结构、索引、存储过程、触发器、数据一致性，哪个环节出问题，业务就得停摆。更别提那些几十TB的库，光导出就得熬几个通宵。去年有个朋友做迁移，结果主键冲突没处理好，上线后订单数据乱了三天，老板亲自打电话道歉。
迁移的第一步，永远不是敲键盘，而是搞清楚到底要迁什么。很多人一上来就想着怎么把数据从 A 搬到 B，结果搬完才发现，某些老表已经没人用了，有些字段存了十年也没人查过。你花三天时间导出一堆垃圾数据，图什么呢？真正该做的，是先梳理业务场景：哪些表是核心交易数据，哪些是历史归档，哪些可以压缩或清理。我见过最聪明的做法，是把迁移当成一次数据治理的机会。利用这个节点，把脏数据清洗掉，把重复的索引合并，把不再需要的存储过程删掉。迁移不是简单的搬运，而是对数据库健康状况的一次体检。
选工具和策略这块，很多人容易犯一个错误——迷信大厂方案。某某云的数据迁移服务、某某数据库厂商的迁移助手听起来很完美，但实际使用时会发现限制一堆。比如有的工具只支持特定版本，或者对表名大小写有要求，又或者遇到大字段直接卡死。我建议先做小规模验证：找几个典型表，用不同工具试跑一遍，记录成功率和耗时。别只看官方文档，要自己去踩坑。有个团队使用某知名迁移工具，结果遇到自增主键的边界问题，数据全写错了，只能回滚重来。工具是死的，你的场景是活的，别让工具牵着鼻子走。
一致性校验是迁移中最容易被忽视的环节。很多人觉得，数据导出来再导进去，只要没报错就行。但数据库里藏着很多隐性问题。比如某个字段是时间戳，源库和新库的时区设置不同，数据看起来一样，实际含义却相差几个小时。再比如浮点数的精度问题，源库是双精度，新库是单精度，数据被截断而你却不知情。我建议迁移完成后做三层校验：第一层是总数比较，行数要对得上；第二层是关键字段的校验码比对，例如对几列做哈希值计算，确保内容一致；第三层是抽检——找几个业务人员，让他们在新库里跑日常查询，看看结果是否和预期一致。这个步骤不能省，也别交给工具全自动完成，人眼过一遍，心里才有底。
业务中断时间是最敏感的指标，也是老板最关心的问题。你不可能为了迁移让业务停三天，那意味着每天损失几十万甚至上百万。所以迁移策略必须考虑流量切换。常见做法是增量同步加灰度切换：先把全量数据导过去，然后开启增量同步，让新库实时接收源库的变化。等两边数据一致后，再把一小部分业务流量切到新库上，观察几个小时，确认没问题后再逐步扩大比例。这个过程像换轮胎，不能停下车来换，必须在行驶中完成。当然，这要求迁移工具支持实时同步，且网络延迟要控制在毫秒级。如果做不到，只能在业务低峰期停机迁移，但时间窗口必须严格控制，超时就回滚。
说点扎心话。数据迁移这事，做成了没人夸你，因为这是分内事；做砸了所有人骂你，因为影响业务。所以心态要摆正，别追求完美，追求的是可控。迁移前写好回滚方案，万一出问题，能在 15 分钟内恢复到原库。迁移中做好监控，CPU、内存、磁盘 I/O、网络延迟，任何指标异常都要报警。迁移后留个观察期，别急着关旧库，至少保留一周。我见过一个团队迁移完觉得万事大吉，第二天就把旧库删了，结果新库的某个存储过程调用报错，查了三天才发现是老库的视图没迁过去，数据已经没了。这种教训一次就够了。迁移不是终点，而是系统演进中的一个节点，你走得稳，后面的路才好走。
