前两天有个朋友找我喝酒，愁眉苦脸地说他们公司要把数据库从 Oracle 迁到 MySQL。我问他要迁多少数据，他说大概三四个 T。我听完差点把啤酒喷出来——三四个 T 的数据迁移，这哥们儿居然只给了两周时间。这事儿在圈子里太常见了，很多人总觉得数据迁移就是把数据导出来再导进去，跟搬家似的。但实际上，Oracle 数据库迁移往往是个无底洞，里面藏着无数意想不到的坑。
先说最基础的问题——数据一致性。很多人以为用 expdp 导出，再用 impdp 导入就完事了。但 Oracle 的数据结构远比想象中复杂，光是约束、触发器和存储过程就够喝一壶的。我在一个项目里遇到过，迁移完数据后发现某些表的序列号全乱了，因为源库和目标库的序列号缓存机制不一样，导致后续业务写入时直接报错。更坑的是索引，Oracle 的索引结构跟 MySQL 完全不同，同样的查询在 Oracle 上跑得飞快，迁移到 MySQL 后直接变成全表扫描。所以千万别以为数据迁移就是简单搬家，你得考虑数据模型、索引策略、查询优化这些深层次的东西。
再说数据量的问题。很多人对“大数据量”没有概念，觉得几百个 G 不算大。但你要知道，Oracle 的数据库文件动辄上 T，光是全量导出一遍就得十几个小时。我见过一个离谱的项目，客户说要迁移 20 T 的数据，结果光导出就跑了三天，中途还因为磁盘空间不足挂了一次。更麻烦的是增量同步，业务不能停，数据还在不断写入，怎么保证迁移过程中的数据不丢失？这时候就需要用 Oracle 的 LogMiner 或者 GoldenGate 来做实时同步，但这玩意儿配置极其复杂，而且对源库性能有影响。很多公司为了省钱不使用专业工具，自己写脚本搞，结果不是丢数据就是数据不一致，还得回滚。
还有个容易被忽视的问题——字符集。Oracle 的字符集千奇百怪，有的是 AL32UTF8，有的是 ZHS16GBK，还有更冷门的 WE8ISO8859P1。如果目标数据库是 MySQL 的 utf8mb4，还好说。但如果迁到 PostgreSQL，字符集不匹配的问题就来了。我处理过一个案例，客户迁移后发现中文全变成乱码，排查了三天才发现是源库的 NLS_LANG 参数设置不对。更隐蔽的是，有些字段里混了全角半角字符，导出导入后排序全乱了。所以迁移前一定要做字符集分析，别等到发现问题再补救。
性能问题也是个坑。很多人觉得迁移完数据就万事大吉，但实际上一跑业务就卡成狗。Oracle 的 SQL 优化器跟 MySQL 完全不一样，同样的 SQL 在 Oracle 上能用索引，在 MySQL 上可能就是全表扫描。我有个客户迁移完一个电商系统，订单查询页面从秒级响应变成了几十秒，用户直接炸了。后来发现是 Oracle 的位图索引在 MySQL 里不支持，只能改成 B‑tree 索引，但改完后查询计划仍不对。不得不重写了一大堆 SQL，把子查询改成关联查询，把分析函数改成临时表方式，折腾了整整一个月才把性能调回来。
迁移过程中的业务连续性也是个头疼的问题。业务不能停，但数据迁移又需要锁表来保证一致性，怎么平衡？很多人选择在凌晨业务低谷期操作，但万一迁移时间超了，早上上班时业务仍在停着，那就等着挨骂。我见过最聪明的做法是用 Oracle 的物化视图做预迁移，提前把历史数据迁过去，只迁增量数据，这样锁表时间能控制在几分钟内。但物化视图的刷新策略也是技术活，刷新频率高会影响源库性能，频率低则增量数据太多，迁移风险反而增加。
数据验证也是容易被忽略的环节。很多人迁完数据后只检查记录数，觉得数字对得上就完事了。但迁移中的“幽灵差异”才最可怕——两条记录看上去一样，却因为精度问题差了那么一点点。比如 Oracle 的 NUMBER 类型在 MySQL 里对应 DECIMAL，但精度设置不对，小数点后几位会被截断。我处理过一个金融系统的迁移，客户发现对账不平，查了半个月才发现是某个累计金额字段的精度设置问题，导致每天少算了 0.01 元，积少成多，半年下来差了十几万。
说个真实案例。去年帮一家物流公司做 Oracle 到 MySQL 的迁移，数据量大概 5 T，计划时间一个月。结果光数据模型映射就花了两周，因为 Oracle 的分区表、物化视图、高级队列这些特性在 MySQL 里没有直接对应，必须重新设计。更糟的是业务方中途提出要保留所有历史数据，但 MySQL 的单表性能瓶颈又摆在那里，只能做分库分表。整个项目超时两倍，预算翻了四倍。事后复盘，最大的教训是——数据迁移不是单纯的技术问题，而是项目管理问题。
所以我的建议是，做 Oracle 数据迁移之前，先花时间做好三件事：第一，数据源评估，弄清楚有多少数据、数据结构多复杂、业务对数据一致性的要求有多高；第二，目标数据库选型，别以为 MySQL 就万能，有时 PostgreSQL 或分布式数据库更适合；第三，迁移策略设计，决定是全量迁移还是增量同步，是停机迁移还是在线迁移，这些都要根据业务场景来定。千万别一上来就搞技术实现，不然坑的是自己。
回到开头那个朋友的项目，后来我给他建议了两件事：一是把迁移时间从两周延长到两个月，二是先做一次小规模试迁移，验证流程和数据质量。他一开始还觉得我小题大做，结果试迁移第一天就发现字符集问题，第二天发现索引策略不对，第三天发现存储过程在 MySQL 里跑不了。他给我打电话说：“哥，幸亏听了你的，不然这回真要翻车了。”我笑着回他：“数据迁移这事儿，跟谈恋爱一样，急不得，越急越容易出问题。”
