陆金所18个月从Oracle迁移MySQL实战复盘

2016年到2018年，陆金所把90%的数据库业务从Oracle搬到MySQL这件事，在当时的数据库圈子里被反复讨论。一个互联网金融平台，手里握着账户、交易、资产端这些实时性和一致性要求极高的核心链路，敢用18个月向Oracle说再见，今天回头看依然是个高风险决策。更让同行好奇的是，交割期间系统整体没有出大的乱子。公开资料里能看到的更多是“发生了什么”，真正有价值的其实是背后的技术路线：哪些业务能迁、哪些不能迁、先迁什么后迁什么、靠什么保证数据不丢不重、出问题时怎么回滚。

这篇文章我会结合自己做MySQL和Oracle迁移时的实操经验，把这个案例的决策背景、技术评估、迁移路线、典型踩坑点完整复盘一遍。准备做数据库迁移的团队、正在做选型的架构师，以及想深入理解Oracle与MySQL差异的同学，可以拿这篇当参考。我没有在陆金所内部待过，文中的方案基于公开分享、技术圈讨论和同类金融项目迁移的通用实践整理，该说明的地方我会说明，不影响你从中提取方法论。

1. 为什么陆金所铁了心要离开Oracle

1.1 商业数据库的授权成本，越到后面越肉疼

先说最直接的动机：钱。Oracle的授权模式不是按用户数，也不是按容量，而是按CPU核心数算License。业务一增长，扩容就是常态，每加一台服务器就多一份授权费用，一年多几十万甚至上百万的维护费也很常见。对一个当时正在快速扩张的互联网金融平台来说，数据库节点从几十个往几百个走，这套成本模型是扛不住的。

更麻烦的是，Oracle企业版的授权费通常还绑定了很多你未必用得上的选件：分区、RAC、Data Guard、高级压缩等等。这些功能每个都是单独计费，为了一个高可用能力可能要多付几倍的License。迁移到MySQL之后，软件授权费直接归零，硬件也能用更便宜的普通X86服务器，这笔账在立项阶段就能算出来。金融科技公司对成本敏感，数据库又是每年IT预算里的大头，老板看到这个对比，基本都会支持“去Oracle化”。

成本之外还有一个隐性账：Oracle的License合规检查很严格，尤其在虚拟化环境下，CPU按物理核还是按虚拟核算？超分怎么算？这些问题经常让运维团队头疼。没有精确的License管理能力，随时可能面临合规风险。把核心业务迁到MySQL，等于把这个包袱彻底丢掉，运维不用再天天统计核数工程量。

1.2 互联网业务的增长节奏，Oracle的架构开始卡脖子

Oracle RAC是一套非常成熟的高可用架构，靠共享存储让多个实例同时读写同一个数据库。小规模时很稳，但扩展性有一个明显的天花板：RAC集群里的节点共享同一份存储，数据库整体能承受的连接数、并发数、数据量，都受限于底层存储和单库容量。

互联网业务的节奏是什么？流量有波峰波谷，业务快速迭代，容量要求随时能横向扩。Oracle在这种场景下非常难受：想扩容，要么把单机配置堆得更高，要么把存储换个更大的阵列，每走一步都是高昂的硬件升级，而且数据库还是只有一个“大库”的逻辑，应用层拆不动它。你可以把Oracle RAC理解成一辆重型卡车：载重强，但你想多拉货时，只能换更大的卡车，没法把货分给十辆小车一起拉。

MySQL生态解决的是另一条路：分库分表。把一个大库拆成几十个库、几千张表，每个分片跑在普通的服务器上，业务增长时加机器就能顶上去。这种纯粹的“横向扩展”模式，天然适配互联网式的流量增长。对一个金融科技平台来说，理财发布、营销活动、行情波动都会带来突发的读写峰值，架构必须能跟着业务一起弹，Oracle在这点上并不擅长。

还有一个容易被忽略的点：RAC依赖共享存储和心跳网络，部署和运维门槛相当高。DBA要维护ASM、监听、集群件、OCR、Voting Disk这一整套组件，排障链路长。MySQL的主从复制、中间件管理相对简单直接，出了问题查binlog、看状态变量，普通DBA就能上手，不需要请外部顾问半夜来救火。

1.3 四选一：为什么是MySQL，而不是PostgreSQL或自研

决定离开Oracle之后，摆在面前的无非四个方向：继续用其他商业数据库、选PostgreSQL、选MySQL、自研或引入分布式数据库。2016年前后，PostgreSQL在国内互联网公司的工程积累远不如MySQL，工具链、人才池、踩坑文档都少一个数量级。分布式数据库当时要么刚起步，要么还带着商业授权的味道，对一个追求稳定落地的团队来说，学习成本和风险都太高。

MySQL反而是当时最“稳妥”的选择。阿里、腾讯、美团这些大厂在MySQL上已经有大量生产级实践，从批量复制、中间件到各种性能优化方案都验证过，社区里能搜到的问题和答案非常丰富。技术圈一直流传一个说法：如果你的问题是MySQL的，大概率在别人那儿已经踩过、发过、修过了，这对一个求快的迁移项目非常关键。

团队因素也不能忽略。陆金所当时的研发团队普遍对MySQL更熟悉，招聘一个会Oracle的DBA，价格贵、周期长；MySQL工程师相对好招，培养路径也短。技术栈统一之后，应用开发、DBA、运维之间的协作门槛会明显降低。选型不是选“最强”的数据库，而是选“最容易让团队趟过去”的数据库，这是迁移项目里非常重要的一条经验。

2. 去Oracle之前，先把技术账算明白

2.1 “90%业务”怎么定标准

很多人看到“90%”这个词，以为是把90%的表迁过去就够了。实际定义要复杂得多：一个业务能不能迁，要看它的请求量占比、逻辑复杂度、数据一致性要求、以及是否重度依赖Oracle的独有特性。通常来说，判断标准可以列这么几条：

• 业务是否只做简单查询和事务写入？比如后台管理、报表查询、运营活动这类系统，迁移风险最低。
• 是否大量使用PL/SQL存储过程、物化视图、分析函数、递归查询这些Oracle强项？SQL越复杂，改造工作量越大。
• 对数据一致性的容忍度有多高？如果要求全局强一致，MySQL在分库分表后要做分布式事务，成本会陡增。
• 数据量是否大到必须分片？如果能用单库扛住，迁移反而省事。

剩下那10%的“不迁”，通常是最难啃的系统，也是最不值得啃的系统。比如分析型报表中心，重度依赖Oracle的分析函数、物化视图刷新，迁移到MySQL后SQL要重写、性能还不一定达标，干脆留着，没必要跟自己过不去。定90%这个目标的核心意义在于：把“迁移收益”和“迁移风险”画了一条清晰的边界，先立靶子再倒排工期，而不是幻想一刀切一个月搞完。

2.2 Schema迁移：字段类型、索引、分区的一次“翻译”

Schema迁移是整个项目的地基。Oracle和MySQL虽然都是关系型数据库，但字段类型、索引行为、字符集、默认值这些细节差异特别多，想当然地直接建表，后面一定会出事故。我整理过一张常用映射表，基本可以覆盖大部分迁移场景：

字段类型映射只是第一步，索引问题更考验DBA的功力。Oracle的函数索引、位图索引、反向索引都非常成熟，MySQL基本不提供同类能力，必须改造成普通B+Tree索引或者换一种查询方案。MySQL组合索引遵循最左前缀原则，原来Oracle里随手建立的索引，到MySQL里可能完全走不上，查询计划直接全表扫描。

分区表的坑也要提前知道。Oracle的分区裁剪性能很好，分区类型丰富，MySQL 5.7的分区表实现并不算理想，官方自己也承认有性能问题。我当时参与迁移时就遇到过：Oracle里一个按时间分区的大表，到了MySQL用RANGE分区，结果查询计划还是扫了整个分区，后来干脆改成按时间分表+应用层路由，反而更简单。迁移团队要有心理准备，MySQL里“单表尽量小吃”比“一个表玩出花”更符合它的人设。

字符集更是重灾区。Oracle常用的AL32UTF8和MySQL的utf8mb4之间，除了字符编码本身，还有排序规则差异。utf8mb4下如果没注意索引长度限制，VARCHAR(255)直接超老版本InnoDB的767字节索引限制，建表就报错。这个细节在开发环境很难暴露，到了生产环境做数据导入时才爆出来，会打乱整个排期。

2.3 SQL与PL/SQL：最大的改造工程量

Schema迁移是体力活，SQL和存储过程改造才是真正的“硬骨头”。Oracle和MySQL的SQL语法看似相近，实际上到处是坑。我列几个最常见的替换场景，能覆盖绝大部分日常SQL：

• 分页：Oracle的ROWNUM，转到MySQL用LIMIT；但深分页性能要重新评估，后面专门说。
• 空值处理：Oracle的NVL对应MySQL的IFNULL，但要注意Oracle里空串会被当成NULL，MySQL不会，这个行为差异会直接影响业务逻辑。
• 日期：Oracle的SYSDATE、TO_CHAR格式串，对应MySQL的NOW()、DATE_FORMAT，格式符号不一样，写错就是乱码。
• 条件分支：Oracle的DECODE函数，MySQL没有，统一改成CASE WHEN。
• 字符串拼接：Oracle用“||”，MySQL要用CONCAT，别小看这个，全库搜一遍能看到几百处。
• 数据合并：Oracle的MERGE INTO，MySQL可以用INSERT ... ON DUPLICATE KEY UPDATE，但语义不完全等价，涉及唯一键冲突时的更新逻辑，必须人工核对。
• 递归：Oracle的CONNECT BY，MySQL 8.0之前没有递归写法，只能应用层自己递归，或者先把数据查出来在代码里处理。

比SQL语法更麻烦的是PL/SQL。金融系统的老库里，业务逻辑大量堆积在存储过程、函数、触发器、程序包里，有的一个存储过程几百行，嵌套循环、自治事务、动态SQL全用上了。MySQL的存储过程能力弱于Oracle，调试和性能都不好，圈内公认的改造思路是：把存库里的逻辑“上浮”到应用层，用Java或Go重写。

这里面最坑的其实是Oracle的自治事务：比如主事务回滚了，日志表却照样写入，MySQL没有等价物。重写Java代码时如果事务边界控制不好，日志和主数据就分叉了。所以SQL改造不能简单做语法翻译，要把业务逻辑完整搬到应用层，并在测试环境做严苛的并发和回滚验证。

2.4 高可用架构的重构路线

Oracle RAC本身就是一套高可用方案，数据共享、节点切换、负载均衡都自带了。切到MySQL后，这套东西全要自己搭。主从异步复制、半同步复制、MHA、MGR，再到分库分表中间件，每层高可用都要重新设计。

当时比较稳妥的组合是这样的：数据库层用主从复制，开启半同步复制尽量缩小主备差异；在从库后面挂一台MHA管理者来做故障自动切换，业务层通过VIP漂移感知主库变化；读写分离在中间件或者应用层做。切换预案要提前演练很多次，因为MySQL的主从切换不像RAC那样对应用完全透明，切换过程中连接会断开，应用必须要有重连和重试机制。

很多团队容易忽略一点：MySQL高可用的瓶颈往往不在数据库本身，而在应用层的连接管理。连接池的探活策略、失败重试次数、事务超时时间，任何一个没调好，主库切换时都会引发雪崩。我见过有项目数据库切得很顺，结果应用层连接池全部挤在一台老主库上重试，直接把库打挂。数据库高可用是一个系统工程，不是DBA一个团队的事情。

3. 18个月迁移路线图，分四个阶段推进

3.1 阶段一（0-3个月）：选型、造工具、定规范

第一个阶段的核心，不是马上动手迁数据，而是把工具和规范准备好。陆金所这类规模的企业，数据库迁移如果没有自动化工具支撑，靠人肉写脚本同步几百个库，18个月根本不够。要做的事情大概有这几类：

• 确定MySQL版本和参数基线，包括缓冲区大小、刷盘策略、连接数上限、binlog格式等，统一部署模板，避免每台实例配置漂移。
• 建设数据同步工具链。全量同步可以用DataX、mysqldump或者自己写导出导入程序；增量同步可以用Canal订阅binlog；数据校验需要写工具，按表和主键做全量/增量比对。
• 做一次全量SQL扫描，把Oracle特有语法、存储过程、触发器按系统分类统计，形成改造工作量清单。
• 定SQL规范。当时最常见的红线包括：禁止SELECT *、禁止在索引列上用函数、禁止大事务、禁止一次更新超过5000行、所有表必须有主键。规范定得越早，后面踩坑越少。

这些工具看起来不起眼，却是整个迁移项目的生命线。没有自动对账，双跑的时候你就不知道两边数据差多少；没有增量同步，核心系统切流后Oracle就成孤岛，回滚都没法切。工具链建设花一个月是值得的。

3.2 阶段二（4-9个月）：边缘业务先行，跑通全链路

第二阶段的核心策略是：先拿最简单的系统练手。报表系统、后台管理、运营后台、BI查询，这些非核心但真实在跑的业务，流量不高，业务容忍度大，非常适合第一批迁移。

这一批系统虽然简单，但整个迁移流程必须完整走一遍：数据全量导过去、增量同步跑起来、应用切到MySQL、观察一段时间、验证数据一致性、保留Oracle作为回滚目标。把全流程跑顺之后，团队就知道哪些工具要补、哪些环节要多留时间、哪些细节之前没想到。

我见过很多团队在这个阶段容易犯一个毛病：觉得“这不就是个查询库吗，直接迁就完了”。结果真查起来才发现，报表系统里塞满了Oracle特有的分析函数，一张报表的SQL几百行，跑在MySQL上怎么调都慢。所以即便第一批系统，也还是要做SQL预检，不要因为是边缘系统就降低改造标准。

3.3 阶段三（10-15个月）：核心系统双写双跑，灰度切换

核心系统是整个项目真正考验功力的时候。账户、交易、资产端这些系统，数据一致性要求极高，直接切是不可能的，必须双写双跑。双写不是说应用层同时写两个数据库那么简单，它要解决事务边界、写入顺序、失败补偿、数据校验一堆问题。

一种常见的做法是应用层主动双写：业务事务里同时写Oracle和MySQL，MySQL写入失败时记录失败日志，用异步任务重放；另一种是靠Canal订阅Oracle的日志同步到MySQL，应用层不做双写，减少代码改动，但实时性和一致性验证要更加谨慎。无论哪种，都要配套一个对账系统，定期按业务流水号、金额汇总做全量校验，出现差异立刻告警、定位、重放。

切换也要讲究节奏。不能一个晚上把全部流量切过去。按用户维度分桶，先放5%的用户试跑一段时间，没问题再加到30%、50%、100%；或者按功能模块，先把查询流量切过去，再把写流量切过去。每次切换前都要检查主从延迟、慢查询量、错误率，并准备好一键回滚按钮。回滚不丢人，乱冲才出事。

3.4 阶段四（16-18个月）：收尾清理，旧库下线

业务全部切完之后，Oracle不能急着下线。两个库并行观察一段时间，一般建议至少1到2个月，把业务跑满一个完整的活动周期，比如月度结算、季度盘点、年末高峰。这期间要对账工具持续跑，确认两侧数据没有任何差异。

观察期结束后，Oracle从读写变成只读，再变成完全停掉，然后回收授权、释放硬件资源。很多人忽略最后一步：Oracle的最后一份物理备份和逻辑备份，必须一直保存到审计周期结束。金融业务有审计要求，哪怕系统下线了，数据也要能随时查出来。

下线的过程也要有仪式感。我当时做迁移项目时，会专门留一个节点，把Oracle集群的停止操作写在变更单里，每一步都拍照留存。因为一旦停错了实例，想再拉起来可能比登天还难，这台机器的环境、补丁、配置可能已经变了。细心和保守，是收尾阶段最重要的态度。

4. 迁移路上那些绕不开的坑，和对应的解法

4.1 深分页查询性能断崖式下跌

这是迁移过程中最容易爆出来的性能问题。Oracle的分页靠ROWNUM，优化器能利用索引快速定位到目标区；MySQL的LIMIT offset,m是先把offset+limit行全查出来，再丢掉前offset行，偏移量越大，扫描越多。后台管理系统里翻到第100页，一条SQL从几十毫秒变成几秒，非常典型。

解决办法我试过三种，效果都不错：

• 游标分页：把“第N页”改成“上一页最后一条ID之后取N条”，WHERE id > last_id ORDER BY id LIMIT 20。这适合列表是按主键或时间排序的场景，性能最稳定，深度无限翻也不会劣化。
• 延迟关联：先查主键，再回表查全部字段。SELECT t.* FROM table t JOIN (SELECT id FROM table WHERE ... ORDER BY id LIMIT 100000, 20) tmp ON t.id = tmp.id; 这样前段扫描只用索引，回表只回20行，性能提升非常明显。
• 上搜索引擎：如果业务允许，列表查询、组合筛选、模糊搜索这些场景，与其死磕MySQL，不如扔到ES件里做。金融项目的搜索场景本来就多，早点引入反而省心。

4.2 存储过程与触发器改造：最脏最累的活

金融系统的老库里，存储过程是真的多。以前我在另一个项目里数过，光核心系统就有上千个存储过程，每个平均几百行，还有包、触发器、函数互相调用。Oracle的PL/SQL调试方便、功能强，MySQL的存储过程能力弱、调试体验差，硬迁不如重写。

我们的做法是：先画出存储过程的调用关系图，按调用链拆分业务逻辑，再逐层用应用代码重写。重写时要注意好几个容易出幺蛾子的点：一是事务边界，一个存储过程里可能有多个隐式事务，应用层重写时如果放在一个Spring事务里，执行顺序和提交时机就变了；二是Oracle的自治事务，写日志不随主事务回滚，Java里要做成REQUIRES_NEW；三是自定义异常，Oracle的EXCEPTION捕获和抛出逻辑跟Java的try-catch完全不同，不能一一对应。

这块工作量通常被严重低估。我的建议是，在排期里把存储过程改造单独列为一条时间线，至少占总项目工期的三成，提前让应用团队介入。越早开始越主动，因为存储过程背后是一批老业务逻辑，改造过程中经常要和业务方确认规则，沟通成本远高过写代码本身。

4.3 大事务、锁等待与数据校验的拉锯战

迁移后跑了一段时间，最容易遇到的是大事务问题。Oracle里一条UPDATE扫个几百万行问题不大，因为有UNDO机制和更宽的锁队列；MySQL里一个UPDATE锁几百万行，不仅自己慢，还会把整个库的锁等待拉高，主从复制延迟一路狂飙。

解决方案说穿了就四个字：分批处理。把一次更新拆成1000行一批，每次提交一个短事务，中间稍微sleep一下再跑下一批。看起来浪费时间，实际上系统整体稳定，主从延迟也降下来了。另外要避免在索引列上用函数做条件判断，否则MySQL会放弃索引，行锁直接上升为表锁，后果非常严重。

数据校验这块，我常用的办法是两层校验。第一层快速上报：对比两张表的COUNT(*)和SUM(CRC32(CONCAT_WS('|', 关键字段们)))，两组值相等就认为基本没问题。第二层抽样全比：按主键抽样，逐字段对比每个值。CRC32会有碰撞概率，所以关键表一定要做第二层。校验频率上，双跑阶段最好每小时跑一次，切换后每天跑一次，稳定后可以放宽到每周。

4.4 字符集、时区与精度：细节里藏着鬼

这类问题在开发环境永远模拟不出来，一到生产切换就集体爆雷。字符集最典型：Oracle里NVARCHAR2和VARCHAR2混用的表，迁移到MySQL统一用utf8mb4之后，中文排序结果可能跟原来不一致。如果业务上有按中文首字母排序的需求，MySQL默认的排序规则根本排不对，得用CONVERT到GBK临时转一下，或者应用层自己处理排序逻辑。

时区也是一个经典坑。Oracle的SYSDATE取数据库服务器系统时间，MySQL的NOW()取的是会话时区时间，Java连接串里没显式指定serverTimezone时，默认值可能跟业务期望差好几个小时。我当时遇到最坑的一次，是迁移后定时任务全部提前8小时触发，排查半天才发现是时区配置问题，跟数据库本身半毛钱关系没有，纯粹是连接串少写了一行参数。

日期精度也是重灾区。Oracle的DATE类型带有完整的年月日时分秒，MySQL的DATE只有年月日，如果迁移时想当然地一一对应映射，所有业务数据的时间部分全部丢失。正确的做法是：只要业务需要保存“时刻”，一律用DATETIME，需要毫秒级精度就用DATETIME(6)，不要用TIMESTAMP。TIMESTAMP在MySQL里有2038年问题，而且受时区影响，在高并发事务下还可能因为自动更新机制产生意外变更，数据模型设计上不如DATETIME干净。

5. 迁移结束之后，这笔账怎么算

5.1 成本和效率的变化，比当初立项时更乐观

授权费每年归零，硬件从高端小型机换成普通X86服务器，扩容的响应周期从“采购审批几个月”变成“申请机器几天”。MySQL天然适合多实例部署，一个业务一个数据库实例，资源隔离做得更干净，某个库出问题不会再拖累全公司系统。这套账算下来，软硬件成本降了一个量级是很有可能的。

但也要说句公道话。迁移期间双库并行，Oracle和MySQL同时在线，存储、计算、运维人力都是双份的；应用改造期间，研发团队的效率短期是下降的。启动一个去Oracle项目之前，老板和项目负责人必须清楚：这笔钱不是省下来的，是前期投入、后期慢慢返还的。按陆金所这个规模，18个月完成大部分系统迁移，后面每年都能持续吃到成本红利，长期来看非常值。

还有一个容易被忽视的收益：MySQL的运维体系更贴合现有监控、发布、容器化平台。数据库可以像应用一样走自动化部署、灰度发布，这在Oracle时代很难想象。基础设施的整体自动化水平被拉高了一大截，这个价值比省下来的软件费更重要。

5.2 团队能力结构的变化，比预想的更深刻

迁移完成后，DBA团队不再天天围着Oracle的ASM、RMAN、GoldenGate转，开始深入理解MySQL的复制原理、性能调优和中间件架构。应用开发同学也明显发生了变化：以前很多逻辑埋在不透明的存储过程里，出了问题只能找DBA看，现在逻辑上浮到应用层，代码评审、单元测试、灰度发布都能覆盖到，整个团队的工程能力上了一个台阶。

人才招聘也更省力。市场上MySQL工程师的数量和培养周期都优于Oracle，技术栈统一后，新同学入职上手速度更快。而且，团队自己掌握了核心数据库的排障能力，不再依赖原厂顾问，故障响应速度反而更快。去Oracle不仅是换了一个数据库，更是把“技术话语权”拿回到了自己手里。

5.3 给后来迁移者的三条实在建议

做数据库迁移这些年，我的体会可以浓缩成三条建议，送给准备动手的团队。

第一条：把“可回滚”三个字刻在脑门上。迁移方案里如果没有一键回滚设计，那就还不是一个可执行的方案。回滚不丢人，切挂了切回去再战，这叫有章法；切挂了硬着头皮修，才叫事故。

第二条：永远不要低估应用层改造的工作量。很多团队把精力都放在数据同步工具上，觉得只要数据搬过去就万事大吉。真实情况是，SQL兼容性、存储过程重构、应用层事务调整、连接池参数优化，每一项都不轻松。给应用改造多留30%的工期，是血泪换来的经验。

第三条：迁移过程不要追求一步到位。90%是一个既务实又有野心的目标：把核心问题解决掉，又允许小部分复杂的系统慢慢消化。数据库迁移最怕定一个100%的KPI，为了几个无关紧要的系统卡住整体进度，得不偿失。

我后来带过几次数据库迁移项目，每次回看陆金所这个案例，都会想起当时圈子里那种又敬佩又怀疑的眼神。技术选型没有绝对的正确答案，重要的是清楚自己要去哪、愿意付出什么成本。数据库迁移从来都不是DBA一个团队的战斗，而是整个研发体系的一次重构。希望这篇复盘，能让你少走几步弯路。