如何通过执行计划分析快速优化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 里高频踩坑点。
为什么加了索引还是不走
常见原因不是索引没建，而是查询条件破坏了索引可用性。
本文共计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 里高频踩坑点。
为什么加了索引还是不走
常见原因不是索引没建，而是查询条件破坏了索引可用性。