上周跟一个做电商的朋友吃饭，他愁眉苦脸地说公司要把Oracle换成MySQL，数据迁移搞了三个通宵还卡在一步。我问他怎么迁移的，他说直接导出SQL脚本再导入，结果报错一堆，字段类型对不上、字符集乱码、存储过程全废了。这种场景太常见了，几乎每个做过异构数据库迁移的人都能讲出一肚子苦水。说白了，异构数据库迁移就像把一栋中式老宅改造成西式别墅，砖瓦结构完全不同，硬拆硬搬只会塌得一塌糊涂。
但这事儿真没法绕开。现在企业上云、国产化替代、降本增效，哪一样都逼着你从老数据库往新数据库搬。Oracle到MySQL、SQL Server到PostgreSQL、DB2到达梦，这些异构组合越来越多。很多人上来就想找个“一键迁移”工具，结果发现要么收费贵得离谱，要么迁移完数据对不上。其实迁移这事儿，核心就三个字：先摸底。你要搬走的数据到底有多大？有哪些表、字段、索引、存储过程、触发器？哪些能自动转换、哪些需要手工重构？这个摸底工作做得越细，后面踩的坑越少。
摸底阶段最容易忽略的是数据质量。我在一个客户那儿见过，Oracle里存了十年的客户数据，姓名字段有的用VARCHAR2(50)，有的用CLOB，还有的直接存了JSON串。迁移到MySQL后，CLOB转成TEXT没问题，但JSON串被当成普通字符串，查询性能直接崩了。更坑的是，有些字段在Oracle里允许空值，到了MySQL由于约束定义不同，导入时直接报错中断。所以迁移前必须做一次彻底的数据清洗，把脏数据、格式不一致、约束冲突都提前处理掉。
工具选型是另一个大坑。市面上开源工具不少，像Apache Sqoop、DataX、Kettle这些，都能做异构数据同步。但问题是它们各有脾气。Sqoop适合批量数据，但对增量同步支持很差；DataX配置灵活，但如果源库和目标库的字段类型映射表不全，你会被各种转换规则搞疯。有一次我用DataX从SQL Server迁到PgSQL，DATE字段在SQL Server里是datetime2(7)，DataX默认映射成timestamp，结果精度对不上，数据全变成了“1970-01-01”。后来手动改了配置文件里的type转换规则才搞定。所以选工具之前，一定先搞清楚你的数据特征：是OLTP还是OLAP？是需要全量迁移还是增量同步？实时性要求高不高？这些参数直接决定你选什么工具、怎么配置。
迁移过程中的性能问题也够让人头疼。几十TB的数据，网卡带宽、磁盘IO、CPU资源，任何一个环节掉链子，迁移时间就奔着几天甚至几周去了。有个银行客户迁移核心交易库，280GB的数据，用默认参数跑DataX，结果源库CPU飙到100%，业务直接受影响，只能半夜跑。后来我们帮他们做了优化：源库侧加上限流参数，目标库侧开启批量提交和并行写入，同时调整了索引重建策略——先关掉索引，等数据导完再重建，速度提升了将近一倍。这事儿说明，迁移不是简单的“搬砖”，你得像调优数据库一样调优迁移过程，否则不仅慢，还可能把生产搞崩。
数据一致性验证是一道防线，也是最容易被忽视的。很多人觉得数据导入完就万事大吉了，结果一查发现少了10万条记录，或者某些字段的值被截断。验证方法有很多，最简单的就是对比行数，但行数对得上不代表数据内容对。更靠谱的做法是随机抽样校验，比如每张表取5%的记录，逐行对比字段值。如果数据量太大，可以用checksum或者hash值做整体比对。我见过最离谱的案例是从Oracle迁到MySQL后，某张表的自增主键ID全变了，导致关联查询全乱套。原因是在MySQL里，自增主键默认从1开始，而原表的主键值本来是从1000开始的。这种细节，你不做深度验证根本发现不了。
迁移完成后的运维切换，考验的是胆大心细。很多团队把迁移和切换放在同一天，结果切换时发现新库性能不如老库，只能回滚。我建议的做法是先做一次“预切换”——在业务低峰期把流量切到新库，跑两小时看看有没有问题，没问题再正式切换。同时要准备好回滚预案：旧库保持在线，数据能反向同步回旧库。另外别忘了监控指标，连接数、慢查询、锁等待、缓存命中率，这些在新库上都要重点盯。有个电商客户在切换后第三天发现MySQL的慢查询日志里全是全表扫描，原来是某些JOIN查询在Oracle里靠索引能跑，到了MySQL因为索引设计不同，执行计划全变了。
说到底，异构数据库迁移不是技术问题，而是管理问题。它考验的是你对数据的理解深度、对工具的掌控能力、对风险的预判水平。那些宣称“零停机、零风险”的厂商，要么是在吹牛，要么是在掩盖某些坑。真正靠谱的做法是：把迁移拆成多个阶段，每个阶段做好验证和回滚准备，宁可慢一点，也别翻车。毕竟数据是企业的命根子，命根子断了，再快的迁移也是白搭。
