awr报告不能直接记录optimizer参数变更，但可通过sql执行统计与执行计划漂移间接反推是否发生改动；关键在于确认“有没有变”及“变在哪条sql上”，而非查找具体修改内容。
AWR报告本身不直接记录Optimizer参数变更，但能通过SQL执行统计与执行计划漂移的间接证据，精准反推Optimizer环境是否被改动过——关键不是找“改了什么”，而是确认“有没有变”以及“变在哪条SQL上”。
为什么单看optimizer_mode或optimizer_features_enable不够用
这些参数可能在会话级、SQL级、甚至隐式hint中被覆盖，而AWR只保存最终生效的执行计划和运行时统计。比如：
-
optimizer_features_enable设为'12.1.0.2'，但某条SQL加了/*+ optimizer_features_enable('11.2.0.4') */，AWR里就只会体现11.2的行为 - 应用连接时执行
ALTER SESSION SET optimizer_mode = FIRST_ROWS_10，该会话后续所有SQL都会受影响，但AWR不会记录这条ALTER语句 -
_optimizer_adaptive_plans这类隐含参数被动态启用后，同一sql_id可能在不同快照中出现多个plan_hash_value，但AWR不告诉你参数何时开关
从dba_hist_sqlstat查plan_hash_value漂移
这是最直接的证据链：执行计划变了，说明Optimizer决策逻辑已不同。重点不是比对两份报告，而是查历史趋势：
- 执行以下SQL确认目标
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);
- 若返回多行，说明至少有两个不同执行路径；如果只有一行但
elapsed_time_total / executions_total同步飙升，可能是统计信息更新或绑定变量窥探（bind peeking）导致计划未变但性能劣化 - 注意
dba_hist_sql_plan默认只保留每条SQL最多1000行执行计划（受_cursor_plan_cache_threshold控制），高频SQL可能被截断，需结合v$sql_plan实时验证
用DBMS_XPLAN.DISPLAY_AWR比对执行计划细节
光看plan_hash_value不同还不够，得确认差异点是否属于Optimizer行为变化：
- 执行：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', 1234567890, NULL, 'BASIC +PREDICATE +NOTE'));对比两个不同plan_hash_value的输出 - 重点关注：
access和filter谓词是否变化（比如从access("ID"=TO_NUMBER(:B1))变成filter("ID"=TO_NUMBER(:B1))）、cardinality预估是否大幅偏差、是否出现adaptive字样或statistics feedback提示 - 若发现
NESTED LOOPS突然替换成HASH JOIN，或INDEX RANGE SCAN退化为TABLE ACCESS FULL，基本可锁定是统计信息、隐含参数或optimizer_dynamic_sampling级别变动所致
关联Instance Efficiency Percentages和Load Profile交叉验证
Optimizer环境变动往往伴随系统级指标异常，不能只盯SQL：
- 如果
Parse To Execute Ratio从95%骤降到60%，大概率是cursor_sharing参数被改（如从FORCE切回EXACT），或应用停用了绑定变量 -
Buffer Hit Ratio未变但db block gets突增2倍，可能是optimizer_index_caching被调高，诱导优化器过度依赖索引 -
Redo size per transaction翻倍且log file sync等待上升，要检查是否commit_write参数被修改，导致事务提交行为改变，进而影响优化器对DML代价的估算
真正难的不是发现计划变了，而是判断“变”是主动调整还是被动失效——比如统计信息过期引发的计划退化，和DBA手动执行ALTER SYSTEM SET optimizer_adaptive_statistics=FALSE，在AWR里都表现为plan_hash_value切换，但根因和修复方式完全不同。必须把dba_hist_sql_plan、dba_hist_sqlstat、v$parameter快照（如果有）三者时间线对齐，才能下结论。
