Oracle 和 MySQL 虽然都是关系型数据库，但在数据类型、SQL 方言、事务机制、对象体系上差异很大，"迁移"从来不是简单的导数据，而是一次架构级的适配工程。本文按迁移的实际流程，梳理各阶段容易踩坑的关键点。

一、迁移前评估

1. 摸清家底，不要只看表和数据量

迁移前先做一次全面的对象盘点：表、视图、索引、约束、序列、触发器、存储过程/函数、Package、Job（DBMS_SCHEDULER）、物化视图、同义词（Synonym）、DBLink 等。MySQL 里很多对象没有直接对应物（比如 Package、Synonym、物化视图），这部分工作量往往比"迁数据"本身大得多，需要单独立项评估。

2. 评估应用层耦合程度

如果应用大量使用了 PL/SQL 存储过程、包、触发器承载业务逻辑，或者依赖了 Oracle 特有的 SQL 语法（如层次查询 CONNECT BY、 ROWNUM、 MERGE 的某些用法、分析函数细节差异），迁移不只是换库，还要重构业务逻辑层。建议先做代码扫描，量化"Oracle 专属写法"的分布，评估重写成本。

3. 明确迁移策略：一次性 or 双写灰度

• 停机迁移：适合数据量小、可接受短暂停机的场景，流程简单可控。
• 在线迁移（双写/增量同步+切换）：适合线上核心系统，需要借助 CDC（变更数据捕获）工具做增量同步，最后做一次极短的切换窗口。这种方式复杂度高，但业务影响小。

二、数据类型与语义差异

这是迁移中最容易"看似成功、实则出错"的部分，务必逐一确认映射关系。

三、对象与语法层面的迁移

1. 主键自增：序列 → AUTO_INCREMENT

Oracle 用 SEQUENCE + 触发器（或 12c 后的 IDENTITY 列）实现自增，MySQL 原生 AUTO_INCREMENT 更简单，但要注意：

• Oracle 序列可以按业务需要独立于表存在、被多张表共用， AUTO_INCREMENT 是与单表绑定的，如果有共享序列的场景需要重新设计。
• 迁移历史数据后，记得用 ALTER TABLE ... AUTO_INCREMENT = N 把自增起点对齐到当前最大值，避免主键冲突。

2. PL/SQL → MySQL 存储过程/函数

PL/SQL 的语法能力（异常处理体系、游标、集合类型、包变量、动态 SQL）远比 MySQL 存储过程丰富。常见做法：

• 简单的过程/函数可以手工或借助工具（如 ora2pg）转写；
• 复杂的业务逻辑，尤其依赖包全局变量、复杂异常体系的，建议直接迁移到应用层（Java/Python 等）用代码实现，而不是死磕在数据库里做等价转换，性价比更高。

3. 触发器

Oracle 支持行级/语句级、 INSTEAD OF、多种时机组合的触发器；MySQL 触发器功能相对有限（不支持 INSTEAD OF 触发器，一张表同一时机同一事件只能有一个触发器，虽然 MySQL 5.7+ 后支持多个但仍有限制）。复杂触发器逻辑建议评估是否能收敛到应用层或改用存储过程显式调用。

4. 分区表

Oracle 分区策略（Range、List、Hash、组合分区）与 MySQL 分区实现方式不同，且 MySQL 分区表存在诸多限制（比如唯一键/主键必须包含分区键）。分区设计通常不能照搬，需要结合 MySQL 的限制重新设计分区方案。

四、SQL 语法差异清单（高频踩坑点）

• ROWNUM（Oracle）→ LIMIT（MySQL），注意 ROWNUM 是在排序前生效的，直接替换成 LIMIT 前要先确认原 SQL 的排序逻辑，否则结果集就变了。
• CONNECT BY 层次查询 → MySQL 8.0+ 用递归 CTE（ WITH RECURSIVE）改写，8.0 以下版本没有原生支持，需要应用层递归或存储过程模拟。
• DECODE / NVL → CASE WHEN / IFNULL（或 COALESCE，兼容性更好）。
• 空表连接、 (+) 外连接语法 → 统一改写为标准 LEFT/RIGHT JOIN。
• 双引号在 Oracle 中通常表示标识符，MySQL 默认情况下双引号表示字符串（除非开启 ANSI_QUOTES sql_mode），大量遗留 SQL 里混用双引号的要特别小心。
• 日期函数体系几乎完全不同（ SYSDATE/ TO_CHAR/ TO_DATE/ ADD_MONTHS 等 vs NOW()/ DATE_FORMAT()/ STR_TO_DATE()/ DATE_ADD()），需要逐个替换并做结果比对。

五、事务与并发模型的差异

• MySQL 常用 InnoDB 引擎，默认事务隔离级别是 REPEATABLE READ，Oracle 默认是 READ COMMITTED，隔离级别不同会直接影响并发读写的行为（幻读、锁等待表现不同），依赖隔离级别语义的业务逻辑要重新验证。
• 加锁行为、死锁探测机制不同，高并发写入场景建议做专门的压测，而不是假设迁移后性能行为一致。
• Oracle 的 ROLLBACK SEGMENT/UNDO 机制与 MySQL InnoDB 的 MVCC 实现细节不同，长事务、大事务的行为（比如回滚代价、undo 表空间占用）也需要重新评估。

六、迁移工具选型

选型时优先考虑：是否需要在线增量同步、数据类型转换的复杂度、团队对工具的掌握程度，而不是单纯看工具的"知名度"。

七、迁移后的校验，不能省

1. 行数与摘要校验：不能只比对 COUNT(*)，建议对关键表做分块校验和（如按主键区间算 MD5/ CHECKSUM），确保数据没有静默损坏或截断。
2. 业务规则回归测试：重点覆盖上面提到的"空字符串 vs NULL"、日期精度、字符集截断这几类隐蔽问题，用真实业务用例跑一遍而不只是技术层面比对。
3. 性能基准测试：Oracle 和 MySQL 的执行计划生成器、索引选择策略不同，迁移后原本高效的查询可能变慢，需要针对高频 SQL 做执行计划分析和索引调优，而不是假设原有索引设计直接适用。
4. 灰度与回滚预案：即便做了充分测试，也建议保留一段时间的双写或可快速回滚到 Oracle 的能力，观察线上真实流量下是否有遗漏场景。

小结

Oracle 到 MySQL 的迁移，技术难度往往不在"把数据搬过去"，而在于两套数据库在类型语义、对象能力、事务模型上的隐性差异——这些差异不会在迁移工具报错时暴露，而是在业务运行一段时间后以数据不一致、性能劣化的形式出现。建议把迁移拆解为"评估—对象转换—数据迁移—双轨验证—灰度切换"五个阶段，每个阶段都留出足够的测试和回滚空间，而不是把迁移当作一次性的数据搬运任务。