如何通过Oracle 19c AWR识别统计信息过期所引起的执行计划改变

确认执行计划是否漂移需查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 pJOIN dba_hist_sqlstat s USING (sql_id, plan_hash_value)WHERE sql_id = 'your_sql_id' AND sample_time > SYSDATE - 7GROUP BY plan_hash_valueORDER 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 的陈旧时间戳，这三者交叉印证，才是定位根因的关键线索。