将原本运行在MySQL上的业务系统迁移到Oracle数据库，是企业技术栈整合或合规要求下常见的动作。两类数据库虽然都遵循SQL标准，但在底层实现、类型系统、事务模型和语法细节上存在大量差异。如果仅用导出导入工具搬运数据和表结构，而不针对语义层面做改造，上线后极易出现写入失败、查询变慢甚至静默数据错误。本文从数据类型、SQL语法和事务控制三个核心维度，梳理迁移过程中必须正视的关键点。
数据类型与自增机制的差异处理
MySQL和Oracle在基础数据类型的映射上并不一一对应。例如MySQL的tinyint(1)常被用作布尔值，而Oracle没有独立的布尔列类型，需要用number(1)配合约束或char(1)来模拟。最麻烦的是文本类型：MySQL的varchar长度按字符计算，Oracle的varchar2在较早版本中按字节计算，若字段存放中文且字符集为AL32UTF8，定义长度需翻倍预留，否则导入会报值过大的错误。
自增主键的实现方式完全不同。MySQL通过auto_increment属性自动生成，Oracle在12c之前没有等价列属性，必须建立序列（sequence）配合触发器或显式在插入语句中调用seq.nextval。即便使用12c以后的identity列，其底层仍是序列，且缓存与排序行为和MySQL不同，批量插入时需注意序值跳跃对业务主键连续性的影响。
下面示例展示如何在Oracle中通过序列与触发器模拟MySQL的自增列：
-- 创建表，注意使用varchar2并指定字节长度
create table orders (
id number(10) not null,
order_no varchar2(32 byte),
amount number(12,2),
create_time date
);
-- 创建序列，步长为1
create sequence seq_orders start with 1 increment by 1;
-- 创建触发器实现插入前自动赋值
create or replace trigger trg_orders_bi
before insert on orders
for each row
begin
if :new.id is null then
select seq_orders.nextval into :new.id from dual;
end if;
end;
/
上述方式在单实例环境工作良好，但在Oracle RAC中若序列未设置order属性，不同节点获取的序值可能乱序，对依赖严格递增主键的消费端会造成困扰。因此高并发场景应评估是否改用应用层发号或UUID，而非强行贴合MySQL习惯。
SQL语法与分页查询的改写要点
分页是业务系统最高频的查询模式，两者语法差异极大。MySQL使用limit和offset即可轻松切片，Oracle在12c前只能借助三层嵌套的rownum伪列，12c后虽支持offset ... fetch next，但优化器行为和索引利用方式不同。直接把limit 10,20替换为rownum between往往导致全表扫描，必须结合排序字段建立合适索引。
另一个隐性坑是隐式转换。MySQL在执行where int_col = '123'时会把字符串转数字并走索引，Oracle则可能因优化器认为类型不匹配而放弃索引，甚至对分区表引发全分区扫描。迁移后应通过explain plan逐一核对核心SQL的执行路径，将代码中的混用类型全部显式转换。
以下代码对比两种数据库的分页写法，以及Oracle中避免rownum陷阱的正确姿势：
-- MySQL原写法
select * from user_log order by id desc limit 20, 10;
-- Oracle 11g及之前用rownum，注意先排序再过滤
select * from (
select t.*, rownum rn from (
select * from user_log order by id desc
) t where rownum <= 30
) where rn > 20;
-- Oracle 12c以后推荐写法
select * from user_log order by id desc offset 20 rows fetch next 10 rows only;
函数差异也不容小觑。MySQL的group_concat在Oracle中要改用listagg，且后者有长度上限需加on overflow处理；ifnull要换成nvl或coalesce；日期加减在MySQL用date_add，Oracle直接用sysdate + 1。这些散落在上千行DAO代码中的函数，建议通过正则扫描加人工复核来清理。
事务隔离与存储过程的迁移陷阱
MySQL默认隔离级别为可重复读（REPEATABLE READ），且InnoDB通过MVCC加间隙锁防止幻读；Oracle默认读已提交（READ COMMITTED），没有间隙锁概念，依靠多版本一致性读保证非阻塞查询。迁移后若应用依赖MySQL的防幻读语义做并发扣减，在Oracle下可能出现重复插入或累计偏差，必须在业务层加唯一约束或悲观锁。
存储过程与函数的迁移工作量常被低估。MySQL的存储过程语法宽松，允许动态SQL拼接较随意，异常处理用declare handler；Oracle的PL/SQL严谨得多，游标cursor需显式打开关闭，异常通过exception when others then块捕获，且编译期就会检查权限与依赖。直接翻译往往通不过编译，更别说性能对齐。
下面给出一个MySQL存储过程向Oracle PL/SQL迁移的简化示例，展示异常处理与游标写法的不同：
-- MySQL过程片段
create procedure upd_status(in uid int)
begin
declare done int default 0;
declare cur1 cursor for select id from task where user_id = uid;
declare continue handler for not found set done = 1;
open cur1;
read_loop: loop
fetch cur1 into @tid;
if done then leave read_loop; end if;
update task set status = 1 where id = @tid;
end loop;
close cur1;
end;
-- Oracle PL/SQL等价改写
create or replace procedure upd_status(uid in number) is
cursor cur1 is select id from task where user_id = uid;
v_tid number;
begin
open cur1;
loop
fetch cur1 into v_tid;
exit when cur1%notfound;
update task set status = 1 where id = v_tid;
end loop;
close cur1;
exception
when others then
if cur1%isopen then close cur1; end if;
raise;
end;
/
除语法外，权限模型也需重新规划。MySQL将库表权限授予账号，Oracle通过角色与同义词管理，应用连接用户通常不直接拥有表，而是经同义词访问。迁移脚本应同步生成角色授权与同义词，否则测试环境能跑的通代码，生产会因ORA-00942表或视图不存在而中断。整体来看，成功的迁移不仅是数据搬运，而是一次完整的语义与架构对齐。