PLSQL_OPTIMIZE_LEVEL不是越高越好，因其优化级别升高会改变代码执行顺序和内联行为：0级兼容旧版但性能差；1级删冗余且顺序不变；2级（默认）平衡性能与稳定性；3级激进重排可能引发隐式依赖错误。
PLSQL_OPTIMIZE_LEVEL 参数确实能影响 PL/SQL 执行速度，但它的作用不是“开开关”就能提速，而是改变编译器对代码的重排和内联策略。盲目调高反而可能引入行为偏差或编译卡顿。
为什么 PLSQL_OPTIMIZE_LEVEL 不是越高越好
这个参数控制编译器对 pl/sql 单元（过程、函数、包体）的优化深度，但不同级别带来的副作用差异很大：
-
0：完全保留 9i 兼容性，禁用现代优化，执行慢，仅用于迁移调试 -
1：删冗余计算和异常检查，不改语句顺序，行为可预测，适合开发阶段快速迭代 -
2（11g+ 默认）：允许跨语句重排、变量提升、部分内联，性能通常更好，但DBMS_OUTPUT.PUT_LINE或异常位置可能偏移 -
3：激进重排 + 自动内联，仅在 12c+ 可用；但若代码含隐式依赖（如靠执行顺序触发初始化），结果可能不可控
实际中，2 是平衡点；3 很少需要手动设——除非你已确认某段高频调用的内部子程序因调用开销成为瓶颈，且测试验证无副作用。
PLSQL_OPTIMIZE_LEVEL 的生效范围与修改方式
它只影响后续新编译的 PL/SQL 单元，对已存在的已编译对象无效。修改后必须重新 CREATE OR REPLACE 或 ALTER ... COMPILE 才会生效：
- 会话级（临时）：
ALTER SESSION SET PLSQL_OPTIMIZE_LEVEL = 2; - 系统级（需重启生效）：
ALTER SYSTEM SET PLSQL_OPTIMIZE_LEVEL = 2 SCOPE=BOTH; - 包/过程级（最精准）：
CREATE OR REPLACE PROCEDURE p AS PRAGMA OPTIMIZE(3); BEGIN ... END;
注意：PRAGMA OPTIMIZE 优先级高于会话级设置，但不能设为 0；且仅对当前单元生效，不影响调用它的其他对象。
容易被忽略的兼容性陷阱
升级数据库（比如从 11g 到 19c）后，即使没动参数，PLSQL_OPTIMIZE_LEVEL 的默认行为也可能变化（例如 19c 对 2 的重排更激进）。常见踩坑点：
- 依赖
EXCEPTION块精确捕获某一行错误，但优化后该行被提前或合并，异常位置漂移 - 包变量初始化逻辑藏在过程体开头，
2级优化可能把它提前到包加载时，导致依赖未就绪 - 用
DBMS_PROFILER或DBMS_HPROF分析性能，但优化后行号映射错乱，定位困难 -
PLSQL_OPTIMIZE_LEVEL=1时，PRAGMA INLINE不生效——这点文档常漏提
真正要提速，别只盯着这个参数。先用 DBMS_HPROF 找出耗时热点，再判断是 SQL 引擎交互多（该上 FORALL）、还是纯计算慢（才考虑升 OPTIMIZE_LEVEL 或换 PLS_INTEGER）。
