AWR报告中“SQL ordered by CPU Time”需先确认DB CPU是否真高：看其占DB Time比重及绝对值，而非仅排Top 5；若DB CPU高但Top SQL合计占比低，问题可能在PL/SQL、解析或递归调用，须结合ASH与DBA_HIST_SQLSTAT交叉验证执行计划变化。
看“SQL ordered by CPU Time”前先确认DB CPU是否真高
AWR报告里CPU time在Top 5 Timed Foreground Events里排第一，不代表CPU就是瓶颈——得看它占DB Time的比重和绝对值。如果CPU time占比45%但DB Time才20秒，实际没压测过；而占比30%但DB Time是1200秒，才是真正CPU密集型负载。别跳过这个判断直接翻SQL列表。
容易踩的坑：DB CPU高，但SQL ordered by CPU Time里头几条SQL加起来只占总CPU的15%，说明大量时间耗在PL/SQL过程、递归调用或解析上，不是单条SQL的问题。这时候得查v$sql里的cpu_time和elapsed_time比值，或者翻ASH按session_state = 'ON CPU'聚合。
别只盯“Elapsed Time”最高的SQL
业务感知的“慢”往往是高频短SQL拖垮响应，比如每秒执行200次、单次elapsed_time才80ms的语句，在“SQL ordered by Elapsed Time”里根本排不进前30——但它可能吃掉60%的Buffer Gets和40%的CPU。真正该抓的是那些executions > 1000且buffer_gets_per_exec > 5000的SQL。
-
buffer_gets_per_exec高 +rows_processed_per_exec低 → 全表扫描缺索引，或谓词未下推 -
disk_reads_per_exec> 10000 → 物理I/O爆炸，优先查执行计划是否走了全表扫描+没走索引 -
parse_calls≈executions→ 硬解析失控，绑定变量漏了或NLS参数漂移
用DBA_HIST_SQLSTAT补AWR默认视图的盲区
AWR报告里的SQL排序只展示Top 30，且不带plan_hash_value变化记录。很多性能抖动源于执行计划突变（比如plan_hash_value从12345变成67890），但报告里看不出。必须自己查DBA_HIST_SQLSTAT：
SELECT sql_id, plan_hash_value, executions,
ROUND(elapsed_time / NULLIF(executions, 0) / 1000000, 2) AS ela_sec_per_exec,
buffer_gets
FROM dba_hist_sqlstat
WHERE snap_id BETWEEN &begin_snap AND &end_snap
AND executions > 100
ORDER BY ela_sec_per_exec DESC;
关键点：ela_sec_per_exec超过1秒且buffer_gets > 10万，基本可断定是低效SQL；同一sql_id在不同快照里plan_hash_value变了，就得立刻查dba_hist_sql_plan对比差异。
关联ASH验证是否真有“高负载”
AWR是聚合统计，ASH才是采样快照。一条SQL在AWR里cpu_time很高，但在ASH里sampled次数极少（比如10分钟内只采到3次），说明它只是偶发长耗时，并非持续负载源。反过来说，如果ASH里某sql_id在session_state = 'ON CPU'状态下被采到上百次，哪怕AWR里没进Top 30，也得立刻拉出来看执行计划。
常用ASH查询：
SELECT sql_id, COUNT(*) samples FROM v$active_session_history WHERE sample_time BETWEEN SYSDATE-1/24 AND SYSDATE AND session_state = 'ON CPU' GROUP BY sql_id ORDER BY samples DESC;
注意：别漏掉sql_plan_hash_value字段——同一sql_id不同执行计划的资源消耗可能差10倍，只看sql_id会掩盖问题。
复杂点在于，高负载SQL往往不是单一维度超标，而是“高频+高逻辑读+硬解析+执行计划漂移”四者叠加。AWR能暴露其中两三个信号，但最后一个信号通常得靠ASH或v$sql实时视图交叉验证。漏掉任意一环，优化就容易打偏。
