Oracle 19c AWR识别统计信息过期引发的执行计划变更

确认执行计划是否真的变了

执行计划“变差”，不一定意味着计划真正“变了”。很多时候，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 上那些陈旧的时间戳——这三者相互印证，才是定位根因的真正线索。