执行计划是否合理，关键看是否存在FULL TABLE SCAN、INDEX FAST FULL SCAN、NESTED LOOPS配高Cardinality驱动表等危险信号；表超10万行仍全表扫描，通常表明索引缺失或谓词写法导致索引失效。
怎么看执行计划是否合理
执行计划不是越短越好，关键看有没有出现 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 ——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 时间戳。
