dbms_xplan.display适合查看预估执行计划，需先执行explain plan for写入plan_table；而display_cursor才从v$sql_plan获取真实执行路径，反映绑定变量、统计信息等实际影响下的计划。
dbms_xplan.display 适合看预估计划，但不反映真实执行路径
它只读 plan_table，而这个表的内容来自 explain plan for 命令——也就是优化器“猜”的执行方式。实际运行时，绑定变量值、统计信息新鲜度、自适应游标共享等都可能导致真正走的计划完全不同。
常见错误现象：DBMS_XPLAN.DISPLAY 显示走了索引，但 SQL 执行慢得反常；或者计划里没看到 FULL TABLE SCAN，线上却在疯狂扫大表。
- 适用场景：SQL 还没跑，只想快速评估写法是否合理；或调试简单语句，无绑定变量
- 必须先执行
EXPLAIN PLAN FOR ...，否则DISPLAY()返回空 - 默认格式是
'TYPICAL'，加'ALL'或'ADVANCED'才能看到Outline Data和Predicate Information - 不带参数调用
DBMS_XPLAN.DISPLAY()会查默认PLAN_TABLE，别误以为它能自动抓最近执行的语句
DBMS_XPLAN.DISPLAY_CURSOR 是监控“刚跑完”SQL 的正确姿势
它直接从库缓存（V$SQL_PLAN）读取真实执行过的计划，包括绑定变量实际值影响下的决策。这才是你该在 PL/SQL Developer 或 SQL*Plus 里查“刚执行完那条 SQL”时用的函数。
使用场景：语句已执行完毕，想确认它到底用了哪个子游标、有没有发生计划突变、谓词是否下推成功。
- 最简调用：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null, null, 'ADVANCED'))—— 查最近一次硬解析/软解析后执行的语句 - 查指定语句必须提供
sql_id和child_number，可从V$SQL中查：SELECT sql_id, child_number, plan_hash_value FROM V$SQL WHERE sql_text LIKE '%collectedtx%' -
'ADVANCED'格式会输出Outline Data，里面包含可用于固化计划的 HINT，比如IGNORE_OPTIM_EMBEDDED_HINTS - 如果查不到结果，大概率是语句还没进库缓存（执行太快被刷出），或权限不足（需
SELECT_CATALOG_ROLE）
用 DISPLAY_AWR 看历史执行计划，但得先有 AWR 快照
当问题发生在昨天晚上，而你登录时那条 SQL 早已不在库缓存里，DISPLAY_CURSOR 就失效了。这时只能靠 AWR —— 它定期采样并持久化执行计划，前提是数据库开了 AWR（企业版默认开，标准版不支持）。
典型错误：直接跑 DBMS_XPLAN.DISPLAY_AWR('abc123...') 却报错 ORA-13780: SQL statement does not exist in the AWR repository。
- 先确认 AWR 是否启用：
SELECT dbid, name FROM v$database+SELECT snap_id, begin_interval_time FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 5 ROWS ONLY -
sql_id必须准确，大小写敏感，且该 SQL 在对应快照周期内确实被执行过 - 若 AWR 没采集到，可临时开启 SQL Monitoring：
SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(sql_id => 'xxx', type => 'TEXT')（需MONITOR权限） - 注意 AWR 默认保留 8 天，老计划可能已被清理，
dba_hist_sql_plan视图才是真源头
PL/SQL Developer 里的 F5 不可靠，别全信
F5 实际就是封装了 EXPLAIN PLAN FOR + DBMS_XPLAN.DISPLAY，本质还是预估计划。它不会告诉你这条 SQL 刚才跑了 12 秒、逻辑读 200 万次，也不会显示自适应计划里中途切换的分支。
容易踩的坑：你在 PL/SQL Developer 里改了绑定变量值再按 F5，看到的仍是旧统计信息下的预估；而生产上真实执行时，变量值一变，优化器可能立刻选错索引。
- 想获得完整上下文，至少要搭配
SET AUTOTRACE TRACEONLY EXPLAIN（命令行）或打开 SQL Monitoring（图形界面） - F5 输出的
Predicate Information区域值得细看，access和filter分开列说明索引是否被有效利用 - 如果 F5 报错
ORA-00942: table or view does not exist，大概率是你当前用户没对PLAN_TABLE的 INSERT 权限，不是 SQL 本身有问题
真实执行计划和预估计划之间的 gap，往往藏在绑定变量值、统计信息延迟更新、动态采样开关这些细节里。别只盯着 ID 和 Operation 列，Predicate Information 和 Actual Rows（后者只有 DISPLAY_CURSOR + STATISTICS 或 10046 trace 才有）才是判断性能瓶颈的关键。
