前几天和一个做技术总监的朋友吃饭，他刚带着团队完成了一次数据库迁移，从老旧的 Oracle 搬到国产数据库。饭桌上他长叹一口气：“三个月没睡过一个好觉，中间差点把核心交易系统崩了，现在想起来后背还发凉。”这种经历我太熟悉了，过去几年采访了不少做数据库迁移的公司，几乎每家都有一肚子故事。数据库迁移听起来是个技术活，实际上更像是一场在钢丝上跳舞的冒险——稍有不慎，几亿条数据、几百个业务系统、上千个接口，随时可能一起出问题。
让我讲一个最典型的案例。一家大型银行要把核心账务系统从 IBM DB2 迁移到分布式数据库，数据量超过 200 TB，涉及 5000 多个存储过程，还有上百个第三方接入系统。项目启动时，技术团队信心满满，觉得“迁移嘛，不就是把数据复制过去”。结果第一次全量迁移就出了大问题——源库和目标库的字符集编码不一致，导致所有汉字字段变成乱码，连“张三”都变成了“??”。更麻烦的是，这些乱码已经同步到了部分测试环境，回滚时发现，有些字段已经被下游系统修改过，数据一致性彻底乱了。整个团队花了整整两周，逐条比对数据，用脚本修复，才把问题解决。
字符集只是开胃菜，真正的大坑在性能差异上。另一家电商公司从 MySQL 迁移到 TiDB，之前在 MySQL 上跑得很顺的 SQL，到了 TiDB 上直接变成全表扫描。一个简单的订单查询，原来 0.1 秒返回，现在要 30 秒。原因是两个数据库的索引实现机制完全不同——MySQL 的 B+树索引对等值查询特别快，而 TiDB 的分布式架构对范围查询更友好。技术团队不得不重写上百条 SQL，把原来依赖索引的查询改成更适合分布式数据库的方式。有个开发吐槽：“这哪是迁移，分明是把整个应用层重写一遍。”但业务部门等不了，每天几百万的订单在跑，每慢一秒都是真金白银的损失。
数据一致性也是让人头疼的事。我跟踪过一个医疗系统的迁移案例，要把患者的电子病历从 SQL Server 迁移到 PostgreSQL。病历数据里有很多二进制字段，比如 CT 影像、心电图波形，这些数据在迁移过程中尤其容易出问题。有一次增量同步时，网络闪断了 3 秒，结果有几十条病历的影像只同步了一半，剩余部分仍留在源库。目标库里的这些“半成品”数据如果被医生调出来诊断，后果不堪设想。项目组不得不在迁移过程中增加校验环节——每迁移一条数据，都要对比源库和目标库的 MD5 值，确保完全一致。这个校验让迁移速度慢了将近一半，但没人敢取消。
还有一个被严重低估的坑是存储过程。很多企业的业务逻辑都写在存储过程里，这些代码往往经过十几年甚至二十年的积累，充满了各种“祖传”写法。我采访过一家保险公司，它们的核心计费系统用的是 Oracle，里面有 3000 多个存储过程。迁移到 GaussDB 时，发现 Oracle 特有的 PL/SQL 语法在 GaussDB 完全不兼容。比如 Oracle 的 “CONNECT BY” 用来做树形查询，GaussDB 没有这个语法，只能用递归 CTE 重写。最夸张的是一个复杂的保费计算存储过程，足足有 2000 行代码，里面嵌套了十几层循环，还用了大量 Oracle 特有的函数包。技术团队花了三周时间，才把它翻译成 GaussDB 能运行的版本。翻译过程中还发现，原来的代码里有一个 bug，导致特定场景下保费计算错误，这个 bug 在 Oracle 上跑了八年都没人发现。
迁移过程中的回滚方案是很多人容易忽视的。大多数项目在规划时都会说“我们有回滚方案”，但真正遇到问题时才发现，回滚可能比迁移更复杂。有个互联网金融公司做过一次从 MySQL 到 OceanBase 的迁移，上线第一天就发现，目标库的分布式事务处理逻辑和原来的单机事务不一致，导致一笔跨账户转账重复执行了两次。团队立即启动回滚，但问题来了——迁移过程中，源库的数据已经发生变化，目标库的数据也被修改。回滚时到底以哪个版本为准？如果完全回滚到迁移前的状态，迁移期间产生的新数据就全丢了；如果部分回滚，又很难保证数据一致性。最终他们启动灾难恢复预案，从备份中恢复数据，系统宕机了 6 小时，被监管部门约谈。
不过，也不是所有迁移都这么痛苦。我见过一个做得特别漂亮的案例，是一家物流公司从 SQL Server 迁移到阿里云 RDS。他们的秘诀是“先搬家后装修”——先把所有数据原封不动迁过去，保持业务正常运行，然后再慢慢重构不兼容的部分。团队使用了一款支持增量同步和实时双向同步的数据迁移工具，意味着迁移过程中源库和目标库同时在线，任何一方的变化都会实时同步到另一方。这样做的最大好处是，业务系统可以随时切换回源库，风险极低。他们花了两个月完成全量迁移和增量同步，又用了一个月做灰度切换——先让 10% 的流量走新库，观察一周没有问题再逐步扩大比例。整个迁移过程零故障，业务部门甚至没有感觉到系统换过数据库。
说点实在的。数据库迁移本质上不是单纯搬数据，而是搬运一个复杂的生态系统。数据本身只是冰山一角，真正难处理的是藏在代码深处的业务逻辑、规则和性能调优经验。很多时候，一个迁移项目能做到“不出大问题”就算成功。我见过太多项目，上线后虽然数据没丢，但性能下降 50%，或者某些边缘功能异常，运维团队要花好几个月填坑。所以，如果你正在考虑数据库迁移，建议先问自己三个问题：第一，真的有必要迁移吗？第二，能否分阶段迁移？第三，是否有足够的预算和人力做全量测试？如果这三个问题的答案都是“是”，再动手；否则，老老实实把现有数据库用好，别为了追新把自己架在火上烤。
