说实话，干数据库迁移这活儿，十个人里有八个头皮发麻。尤其是 PL/SQL 那堆存储过程、触发器和函数，牵一发动全身，稍微一个疏忽就能让整个系统崩掉。我见过太多人，明明在测试环境跑得好好的，一到生产环境就翻车。不是字段类型对不上，就是权限没给够，或者字符集乱码，搞得凌晨三点还在和 DBA 吵架。说穿了，PL/SQL 迁移不是搬数据那么简单，它更像是一场精密的外科手术，得把每根神经都理清楚。
PL/SQL 最坑人的地方，就是不同数据库之间的语法差异。Oracle 里的 函数，到 MySQL 里得换成 ； 变成 ； 在 PostgreSQL 里对应 。看似都是小改动，但如果碰上几百个存储过程，手动改一遍就成噩梦。我有个朋友，去年把 Oracle 迁到华为 GaussDB，光改 PL/SQL 就花了三周，改完还得一个个测。测试时发现有些嵌套循环在 GaussDB 里跑得特别慢，又得重新优化。他后来跟我说，早知道这么折腾，当初就该直接用工具做语法转换。
说到工具，很多人第一反应就是拿个脚本把整个库倒出来，然后往新库里导入。这思路在纯数据迁移时没问题，但碰到 PL/SQL 就太天真了。PL/SQL 里藏着各种隐式依赖，比如一个存储过程调用了另一个包里的函数，那个函数又引用了某个表。你要是按字母顺序一个个创建，八成会报错。更麻烦的是，有些视图或同义词是跨库的，源库和新库的环境不一样，跑起来就报“对象不存在”。我见过最夸张的一次，有个公司从 Oracle 迁到 OceanBase，光梳理依赖关系就花了一周，画出来的依赖图比蜘蛛网还密。
字符集也是个暗坑。很多老系统用的是 GBK 或 ZHS16GBK，新库默认 UTF8，表面上转换工具能处理，但 PL/SQL 里那些字符串操作的逻辑就尴尬了。比如用 截取中文字符，在 GBK 下按字节截取，到 UTF8 下按字符截取，结果会出现半个乱码。还有人喜欢在存储过程里写硬编码的字段长度，像 ，迁移到 MySQL 的 ，看起来一样，实际上 MySQL 的 20 表示字符数，Oracle 的 20 表示字节数，存中文时长度就会变。这些细节不提前排查，上线后数据对不上，哭都来不及。
除了语法和字符集，性能差异也得提前摸底。Oracle 的 PL/SQL 优化器很聪明，能自动处理一些复杂的查询重写，但换到其他数据库，同样的存储过程执行计划就会改变。比如 Oracle 里用 批量处理数据，在 PostgreSQL 里没有对应语法，只能换成游标循环，性能可能掉一个数量级。更隐蔽的是，有些 PL/SQL 里用了 优化，像 ，新库根本不识别，执行计划就乱套了。我建议在迁移前，先挑几个核心的存储过程在新库上做压力测试，看看性能瓶颈在哪，别等到上线才发现跑不动。
权限问题也得细查。Oracle 里一个用户有 DBA 权限，能访问所有表，但 MySQL 的权限是逐库逐表设置的。迁移后，原本能跑的存储过程可能因为没授权直接报“权限不足”。还有那些使用了 的存储过程，在 Oracle 里以调用者身份运行，但到某些数据库后默认是定义者权限，逻辑就全变了。我处理过一个案例，客户从 Oracle 迁到达梦，有个存储过程在源库能正常调用，迁移后总报“表或视图不存在”，查了半天才发现是权限问题——达梦默认使用定义者权限，而那个表只有调用者有权限。
别忘了测试环境的搭建。很多人图省事，直接把整个库 DDL 导出，在新库上一跑就完事。但这种做法基本等于埋雷。PL/SQL 里那些 和 的逻辑，在不同数据库的事务隔离级别下表现完全不同。Oracle 默认是读已提交，MySQL 的 InnoDB 也是读已提交，但 PostgreSQL 的读已提交行为有细微差异。要是存储过程里用了自治事务，或者依赖了 Oracle 的 特性，迁移后行为可能直接走样。我建议至少做三轮测试：第一轮验证语法正确性，第二轮验证业务逻辑一致性，第三轮做并发压力测试，确保高并发下不出幺蛾子。
说白了，PL/SQL 迁移这事没有捷径可走。那些号称“一键迁移”的工具，最多帮你解决 80% 的问题，剩下的坑只能靠人工填。但反过来想，这也是梳理系统底层逻辑的好机会。很多老系统跑了好几年，PL/SQL 里堆满了没人维护的废弃代码，借着迁移正好做个大扫除。比如那些十年没动过的触发器，或者写死表名的存储过程，该删就删，该重构就重构。我见过一个团队，迁移后把原来 300 多个存储过程精简到 150 个，性能反而提升了 30%。所以说，别把迁移当苦差事，它更像是给老系统做一次彻底的体检，疼是疼了点，但做完之后系统会健康很多。
