需逐行比对dba_hist_sql_plan中operation、options、object_name及access/filter_predicates，而非仅依赖plan_hash_value；执行计划突变主因是统计信息更新（尤其直方图）、绑定变量窥探异常值、隐式类型转换；稳定计划首选sql plan management（spm），捕获并固定已验证的好计划。
怎么看awr里同一个sql的执行计划是否变了？
直接查 dba_hist_sql_plan，但别只比对 plan_hash_value —— 它相同不代表计划真一致（比如谓词变了、访问路径微调但 hash 没变）。必须结合 dba_hist_sqlstat 查不同快照（snap_id）下的 plan_hash_value，再按 sql_id + plan_hash_value + snap_id 关联到 dba_hist_sql_plan，逐行比对 operation、options、object_name 和关键 access_predicates/filter_predicates。
常见错误是只看 AWR 报告首页的“Top SQL”表格，它只显示当前快照的 plan hash，看不出历史漂移。真正要定位变化点，得用如下查询定位两个快照间 plan hash 不同的记录：
SELECT sql_id, plan_hash_value, snap_id FROM dba_hist_sqlstat WHERE sql_id = 'your_sql_id' AND snap_id IN (12345, 12346) ORDER BY snap_id;
然后分别拉出这两个 PLAN_HASH_VALUE 对应的完整执行计划做文本 diff。
为什么执行计划会突然变？重点盯这几个地方
不是统计信息一更新就必然换计划，但以下三类变更大概率触发重解析和计划漂移：
-
DBMS_STATS.GATHER_TABLE_STATS时加了method_opt => 'FOR ALL COLUMNS SIZE AUTO'，尤其当列上有倾斜值（如状态字段大量为'N'），直方图生成后优化器可能放弃索引走全表扫描 - 绑定变量窥探（
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES关闭时）遇上首次执行传入异常值（如:status = 'Y'仅占 0.1%），导致生成专为该值优化的计划，后续普通值复用该计划就变慢 - 隐式类型转换：
WHERE order_id = '12345'（字段是NUMBER）会强制加TO_NUMBER()，索引失效，而统计信息里没体现这个转换开销，优化器误判成本
怎么让关键复杂SQL的计划稳定不飘？
SQL Plan Management（SPM）是 Oracle 11g 起最靠谱的稳态手段，比 outline 或固定 cursor_sharing 更可控。操作分三步：
- 先用
DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE把当前已验证过的“好计划”捕获进基线（注意指定sql_id和plan_hash_value，别漏掉fixed => 'YES'） - 确认基线启用：
SELECT sql_handle, plan_name, enabled, accepted, fixed FROM dba_sql_plan_baselines WHERE sql_text LIKE '%your_query%';——fixed = 'YES'才强制锁定 - 避免误删：基线默认随对象删除而清除，若表重建或分区交换，需手动用
DBMS_SPM.ALTER_SQL_PLAN_BASELINE重新绑定
别依赖 OPTIMIZER_USE_SQL_PLAN_BASELINES=TRUE 就万事大吉——如果新生成的计划被接受（accepted = 'YES'）但未设 fixed，下次统计信息刷新仍可能切过去。
AWR报告里看到“Elapsed Time”高，但“CPU Time”低，说明什么？
这是典型的等待驱动型性能问题，和执行计划本身关系不大，优先查等待事件而非调优 SQL 结构。重点关注：
-
db file sequential read：单块读多，常因索引深度大、回表频繁，或缓存命中率低（Buffer Cache Hit Ratio -
enq: TX - row lock contention：有行锁争用，检查是否在复杂查询里用了SELECT ... FOR UPDATE或未提交事务阻塞 -
direct path read：大量物理读，可能是 PGA 不足导致临时段写入磁盘（看PGA_AGGREGATE_TARGET是否合理，以及v$pgastat的cache hit percentage）
这时候改索引、加 hint 都是白忙——先解决 I/O 或锁瓶颈，等等待降下来，再看执行计划是否还值得动。
