聊数据迁移这事儿，得先承认一个现实：现在很少有公司能用一套数据库打天下了。十年前，大家还在纠结用Oracle还是MySQL，现在倒好，一个系统里可能同时跑着关系型数据库、文档数据库、时序数据库，甚至图数据库。异构数据库迁移，说白了就是把数据从A搬到B，但A和B可能连脾气秉性都不一样——MySQL是事务型选手，HBase是列式存储的硬汉，MongoDB又是个自由散漫的JSON爱好者。你让它们对话，就像让一个只会说四川话的人去跟广东菜市场的大妈讨价还价，翻译不到位，分分钟翻车。
我见过太多翻车的案例。有个做电商的朋友，把用户订单数据从PostgreSQL迁移到TiDB，结果跑了一周才发现，订单里的时间字段在源库是字符串格式，到目标库被自动转成了时间戳，导致所有时区错乱。用户凌晨下单，后台显示下午三点。这还不是最惨的，最惨的是数据迁移过程中，源库还在不停写入新数据，迁移脚本没做好增量同步，两边数据差了十万八千里。只能回滚，业务停了整整两天，老板差点把技术负责人骂到辞职。这种事故背后，暴露出一个核心问题：很多人把数据迁移想得太简单，以为就是个“导出导入”的体力活。
真正懂行的人都知道，异构迁移的难点从来不在数据搬运本身，而在数据模型的对齐。举个例子，你源库用的是MySQL，表结构规规矩矩，有主键有外键有索引。目标库换成MongoDB，人家压根不认关系型那一套，文档里可以嵌套数组，可以动态加字段。你强行把MySQL的行记录转成JSON文档，外键关系怎么办？多表关联查询怎么处理？有些团队图省事，直接把所有关联表的数据拼成一个大JSON塞进去，结果查询性能差到令人发指。更夸张的是，有些字段在源库是枚举类型，比如性别字段只有“男”“女”两个值，目标库的枚举定义却可能不同，或者干脆不支持枚举。这种细枝末节的对齐，才是真正烧脑的地方。
数据一致性是另一道鬼门关。很多迁移方案喜欢用“双写”策略——新老系统同时写入，等数据稳定再切换。听起来完美，实际操作起来全是坑。你双写的时候，新系统可能对某些字段有校验逻辑，老系统没有。比如老系统允许邮箱字段为空，新系统要求必填，结果双写时老系统一条数据写进去了，新系统直接报错。还有更隐蔽的问题：分布式环境下的数据顺序。老系统是单机事务，新系统是分布式架构，同一个用户的操作在源库是串行的，到了目标库可能被并发执行，导致最终结果不一致。我见过一个金融项目，迁移时没处理好分布式锁，导致用户余额被重复扣款，财务对账对了一个月才揪出问题。
工具选型同样让人头疼。市面上号称能解决异构迁移的工具一大堆，从开源的DataX、Canal，到商业化的阿里云DTS、AWS DMS，每个都吹得天花乱坠。但实际用下来，没有一个是万能的。DataX对结构化数据支持好，但遇到半结构化数据就抓瞎；Canal擅长MySQL到Kafka的实时同步，但做全量迁移效率低下。最坑的是，很多工具对数据类型的映射规则是黑盒——你只知道它把int转成了bigint，但不知道它为什么这么转。有些团队为了省事，直接用ETL工具加一层中间表做转换，结果数据量一大，中间表成了性能瓶颈，迁移速度比蜗牛还慢。说到底，工具只是辅助，真正靠谱的方案还得靠人根据业务场景做定制。
还有一个容易被忽视的点：迁移过程中的业务影响。很多公司选在凌晨做迁移，觉得用户少就不会出事。但凌晨往往是系统做数据备份、日志清理的时间段，磁盘I/O本来就高，你再跑一个全量迁移，几个任务抢资源，系统直接卡死。更离谱的是，有些迁移脚本没做限流，网络带宽被占满，导致线上业务响应延迟飙升。有个做直播的客户，迁移过程中用户连弹幕都发不出去，直接冲上热搜。所以现在成熟的团队都会做灰度迁移——先迁移冷数据，再迁移热数据，最后才切读写流量。每一步都要有回滚预案，而且回滚速度必须控制在分钟级别。
再说说数据校验这个环节。很多人以为数据搬过去就完事了，结果上线第一天就被用户投诉数据不对。原因很简单：迁移过程中数据可能被隐式修改。比如MySQL中的Decimal类型，精度是小数点后两位，到了目标库的浮点型，精度变成六位，看起来数据没变，但实际存储值已经不同了。还有字符串的字符集问题，源库是utf8mb4，目标库是gbk，中文汉字可能直接变成乱码。更隐蔽的是空值和默认值的处理——源库允许NULL的字段，目标库可能定义了NOT NULL，迁移时自动给了一个默认值，导致业务逻辑出错。所以现在正规的迁移方案，都会在迁移前后做全量数据校验，逐行对比哈希值，有一行不对都要报警。
说句实在话：异构数据库迁移，本质上是一场对业务理解深度的考试。你选的工具再先进，如果搞不清楚业务数据背后的逻辑，该你踩的坑一个都不会少。比如电商系统中的“订单状态”字段，看似就是个枚举值，但它的状态流转逻辑可能涉及几十个业务分支。你直接把它搬过去，新系统能识别吗？还有历史数据中的脏数据——老系统运行了十年，积累了多少不规范的数据，比如手机号格式不对、日期字段填了“00-00-00”，这些在新系统里可能直接报错。所以真正靠谱的迁移，从来不是技术活，而是业务梳理活。你得先花时间把数据字典吃透，把业务逻辑理清，甚至把老系统的历史bug都翻出来。只有这样，才能避免从一个坑跳进另一个坑。
