如何通过执行计划分析快速优化Oracle存储过程缓慢问题？

本文共计904个文字，预计阅读时间需要4分钟。

相关专题

怎么看执行计划是否合理

执行计划不是越短越好，关键看有没有出现 full table scan、index fast full scan（非选择性索引扫描）、nested loops 配合高 cardinality 驱动表这些危险信号。尤其当目标表行数超 10 万，却还在走全表扫描，基本可以判定索引缺失或谓词写法导致索引失效。

用 EXPLAIN PLAN FOR + DBMS_XPLAN.DISPLAY 是最直接方式：

EXPLAIN PLAN FOR SELECT * FROM orders WHERE order_date > TO_DATE(:p_date, 'YYYY-MM-DD'); SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

注意检查 Predicate Information 区域：如果看到 access("ORDER_DATE">TO_DATE(:P_DATE,'YYYY-MM-DD'))，说明用了函数包裹绑定变量，索引大概率没走——这是 19c 里高频踩坑点。

为什么加了索引还是不走

常见原因不是索引没建，而是查询条件破坏了索引可用性。以下情况会让索引“隐身”：

• WHERE UPPER(name) = :val —— 函数作用于列上，索引失效
• WHERE status IN ('A','B') AND ROWNUM <= 100 —— ROWNUM 位置不当，优化器放弃索引范围扫描
• WHERE col1 + col2 = 100 —— 表达式计算，无法利用单列索引
• 绑定变量类型与字段类型不一致，比如 NUMBER 字段传入字符串型 :p_id，触发隐式转换

验证方法：把绑定变量替换成字面量重跑执行计划，如果这时走了索引，问题就出在绑定变量或类型匹配上。

游标循环里反复解析 SQL 怎么办

存储过程中写 FOR rec IN (SELECT ...) 看似简洁，但如果这个 SELECT 带有动态条件且未绑定，每次循环都会硬解析一次——19c 共享池压力会直线上升。

正确做法分三步：

• 把游标声明为 STATIC 形式，显式加 BIND 变量： CURSOR c_data(p_dt DATE) IS SELECT id, amt FROM t_log WHERE log_time > p_dt;
• 在循环外打开，避免重复解析：OPEN c_data(v_start_date);
• 若需批量处理，改用 BULK COLLECT + FORALL，别在循环体内拼接 EXECUTE IMMEDIATE

特别注意：PL/SQL 中的隐式游标（如 SELECT ... INTO）也受绑定影响，别以为只有显式游标才要管。

执行计划突然变差怎么快速回滚

19c 的自适应执行计划和统计信息自动收集可能让某天凌晨后执行计划“漂移”，原来走索引的变成全表扫描。别急着改代码，先做三件事：

• 查历史执行计划：SELECT * FROM DBA_HIST_SQL_PLAN WHERE sql_id = 'xxx' ORDER BY TIMESTAMP DESC
• 锁定旧计划（用 SQL Profile 或 SQL Plan Baseline），命令示例：DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => 'abc123')
• 临时禁用自适应特性：ALTER SESSION SET "_optimizer_adaptive_plans" = FALSE（仅用于定位，勿长期开启）

真正容易被忽略的是：执行计划变化往往伴随统计信息更新。哪怕你没手动 DBMS_STATS.GATHER_TABLE_STATS，19c 默认开启的自动任务也可能已刷新过。所以查计划前，先确认 LAST_ANALYZED 时间戳。