oracle的pl/sql存储过程无法直接在mysql上运行，因两者语法与功能差异极大：mysql不支持%rowtype、%type、raise_application_error、包、自治事务等pl/sql特性，且触发器模型、事务控制、函数映射均需重写，迁移必须人工校验并重构逻辑。
Oracle的PL/SQL存储过程不能直接运行在MySQL上
MySQL的存储过程语法（CREATE PROCEDURE）和PL/SQL差异极大，不是简单替换关键字就能跑通。比如Oracle中常见的 DECLARE ... BEGIN ... END; 块结构、%ROWTYPE、%TYPE、RAISE_APPLICATION_ERROR、包级变量等，在MySQL里全都不支持。
实操建议：
- 先用工具（如ZTO2M或OracleToMysql）做初步语法转换，但必须人工逐行校验——工具生成的
DECLARE变量声明、异常处理块、游标写法往往语义错位 - Oracle中带
OUT或IN OUT参数的过程，在MySQL里需改用INOUT，且调用时必须传变量（不能传字面量），否则报错ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA - 避免在MySQL存储过程中嵌套复杂事务逻辑：MySQL不支持保存点外的跨语句回滚控制，
ROLLBACK TO SAVEPOINT后继续执行容易出状态不一致
触发器迁移要重写逻辑，尤其注意触发时机与限制
Oracle触发器支持 BEFORE/AFTER ROW/STATEMENT + INSERT/UPDATE/DELETE 的全部组合，MySQL只支持 BEFORE/AFTER + FOR EACH ROW，且不支持 STATEMENT 级触发器。这意味着原Oracle中用于统计更新次数、批量操作前预校验的触发器，在MySQL里必须拆成应用层逻辑或用临时表+事件模拟。
常见错误现象：
-
NEW.column_name在BEFORE INSERT中可赋值，但在AFTER INSERT中读取会报错Unknown column 'NEW.xxx' in 'field list' - Oracle中触发器内可调用存储过程，MySQL中触发器内禁止调用含事务控制（
COMMIT/ROLLBACK）或动态SQL（PREPARE）的存储过程 - MySQL单个表最多定义6个触发器（
BEFORE/AFTER × INSERT/UPDATE/DELETE），超限会报ERROR 1359 (HY000): Trigger already exists，需合并逻辑
替代方案比硬改存储过程更可靠
很多业务逻辑其实没必要塞进数据库层。Oracle重度依赖PL/SQL是因为其连接池成本高、应用层计算能力弱；而现代Java/Go服务+连接池+ORM已足够健壮，把原来放在包（PACKAGE）里的校验、组装、日志逻辑移到应用层，反而更易测试、灰度和监控。
可落地的选择：
- 用
MyBatis或JPA @PreUpdate替代BEFORE UPDATE触发器 - 用消息队列（如RocketMQ）解耦异步动作，替代Oracle中
AFTER INSERT调用远程接口的模式 - 对强一致性要求的场景（如库存扣减），用MySQL的
SELECT ... FOR UPDATE+ 应用层CAS重试，比模拟Oracle包级锁更可控
别忽略隐式依赖：序列、系统包、自治事务
Oracle里一个看似简单的存储过程，可能暗地依赖 DBMS_OUTPUT 打日志、DBMS_LOCK 做同步、SEQ.NEXTVAL 生成ID。这些在MySQL里统统不存在。
关键改造点：
-
SEQ.NEXTVAL→ 改用AUTO_INCREMENT或外部ID生成器（如Snowflake），注意前者不保证连续性（见坑1） -
DBMS_OUTPUT.PUT_LINE→ 删除或重定向到应用日志，MySQL无对应机制 - 自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）→ MySQL不支持，必须拆成独立HTTP调用或异步任务 - Oracle中
TO_DATE、TO_CHAR、NVL等函数需映射为MySQL的STR_TO_DATE、DATE_FORMAT、IFNULL，且参数顺序、默认格式常不同
真正卡住进度的，从来不是语法转换本身，而是那些散落在包体注释里、DBA口头交代过、甚至没文档的隐式行为——比如某个触发器实际承担了“防止跨月重复计费”的职责，而代码里只写了 -- check period。这类逻辑必须拉上原开发一起走读，光看SQL是找不到的。
