确认执行计划是否漂移需查awr中同一sql_id是否出现多个plan_hash_value，多行结果表明计划漂移；再核对统计信息last_analyzed时间及直方图状态，过期统计信息会导致cardinality预估偏差，进而引发基线失效或计划变差。
查 awr 里 plan_hash_value 是否真变了
执行计划“变差”不等于“变了”，得先确认是不是统计信息过期触发了计划漂移。awr 是唯一记录真实执行路径的来源，dba_hist_sqlstat 里同一 sql_id 出现多个 plan_hash_value，才是漂移铁证。
运行这个查询（把 'your_sql_id' 换成实际值）：
SELECT plan_hash_value, COUNT(*), MIN(sample_time), MAX(sample_time) FROM dba_hist_sql_plan p JOIN dba_hist_sqlstat s USING (sql_id, plan_hash_value) WHERE sql_id = 'your_sql_id' AND sample_time > SYSDATE - 7 GROUP BY plan_hash_value ORDER BY MIN(sample_time);
- 返回多行 → 计划确实漂移，继续查统计信息是否过期
- 只有一行 → 性能下降大概率不是执行路径问题，可能是 I/O 抖动、锁争用或内存压力
-
dba_hist_sql_plan默认每sql_id最多存 1000 行计划，高频 SQL 可能被截断，空结果不等于没历史计划
核对统计信息最后更新时间与直方图状态
统计信息过期最直接的表现是 last_analyzed 时间太老，或关键列缺失直方图——尤其在 WHERE 条件含非均匀分布字段（如状态码、类型码）时，优化器会误判选择性。
重点查三类对象：业务核心表、关联频繁的维度表、过滤条件涉及低基数字段的表。
- 查过期表：
SELECT owner, table_name, last_analyzed FROM dba_tables WHERE owner IN ('PROD') AND last_analyzed - 查直方图缺失：
SELECT column_name, histogram FROM dba_tab_col_statistics WHERE table_name = 'ORDER_HEADER' AND owner = 'PROD' AND histogram = 'NONE' - 别只看
last_analyzed，还要结合数据变更频率：比如某表每天增量 5%，但统计信息三个月没更新，基本可判定失真
用 DISPLAY_AWR 对比谓词和 cardinality 预估
plan_hash_value 相同 ≠ 性能一致。统计信息过期常导致 cardinality 预估严重偏离实际（比如预估 100 行，实际返回 10 万行），进而引发嵌套循环膨胀、临时空间耗尽等问题。
必须用 DBMS_XPLAN.DISPLAY_AWR 查具体计划，且带上 +PEEKED_BINDS 和 +NOTE：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR( sql_id => 'your_sql_id', plan_hash_value => 1234567890, db_id => 123456789, format => 'BASIC +PEEKED_BINDS +NOTE' ));
- 重点看
access和filter谓词是否合理：比如access("STATUS"='P')应该走索引，若变成filter("STATUS"='P')且出现在全表扫描节点下，就是统计信息误导优化器 - 对比不同快照中同一
plan_hash_value的cardinality：若某次快照里预估 1，实际返回 50000，而另一次预估 48000，说明统计信息刚更新过 - 不加
+PEEKED_BINDS就看不到绑定变量实际值，容易把“窥探失效”误判为“SQL 写法问题”
确认基线是否因统计信息过期而失效
即使建了 SQL Plan Baseline，统计信息过期也会让基线“形同虚设”——优化器可能拒绝使用它，转而生成新计划，尤其当 cardinality 预估偏差超过阈值时。
- 查基线状态：
SELECT sql_handle, plan_name, enabled, accepted, fixed FROM dba_sql_plan_baselines WHERE sql_text LIKE '%your_key%' - 查 AWR 中是否真用了基线：用
DISPLAY_AWR(..., 'ADVANCED')，找 Note 区是否有SQL plan baseline used—— 没这行，基线就等于没生效 - RAC 环境下必须逐实例查
gv$sql或dba_hist_active_sess_history，单节点结果不能代表全局 - 基线启用但未演进时，若统计信息更新后旧基线不再适配，
accepted=NO会导致优化器跳过它，直接走新（差）计划
统计信息过期的隐蔽性在于：它不报错、不告警，只悄悄让执行计划从“刚好够用”滑向“不可接受”。AWR 里 plan_hash_value 的波动、cardinality 的离谱预估、last_analyzed 的陈旧时间戳，这三者交叉印证，才是定位根因的关键线索。
