确认执行计划是否真的变了
执行计划“变差”，不一定意味着计划真正“变了”。很多时候，SQL 查询性能下降，并非因为优化器切换了执行路径，而是原有路径由于某些隐性因素不再高效。要准确判断是否存在计划漂移，AWR 报告是最可靠的证据来源。从 dba_hist_sqlstat 中查看同一 sql_id 是否出现了多个不同的 plan_hash_value，这才是真正的计划漂移。
运行以下查询，只需将 'your_sql_id' 替换为实际 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 < SYSDATE - 30; - 检查直方图缺失：
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 万行。这种偏差会引发嵌套循环膨胀、临时空间耗尽等连锁反应，严重影响 SQL 性能。
此时必须使用 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 上那些陈旧的时间戳——这三者相互印证，才是定位根因的真正线索。
