要看“sql ordered by gets”需计算buffer_gets_per_exec（buffer_gets/executions），重点关注该值>100000且rows_processed_per_exec远低于它的sql，结合执行计划变化、等待事件及pl/sql调用链综合判断真实瓶颈。
怎么看“SQL ordered by Gets”才不算白看
AWR报告里“SQL ordered by Gets”列的是buffer_gets总量最高的SQL，但直接抄Top 10去优化，大概率跑偏——因为buffer_gets高不等于单次执行有问题。真正要盯的是buffer_gets_per_exec（逻辑读/执行次数），它反映单次执行的路径效率。
- 如果某SQL的
executions是5000次，buffer_gets是200万，那buffer_gets_per_exec才400，基本健康；但若executions只有5次，buffer_gets却有200万，buffer_gets_per_exec就是40万，这就是典型路径膨胀 - 报告里不直接显示
buffer_gets_per_exec，得自己算：buffer_gets / executions，注意避开executions = 0的除零错误 -
buffer_gets_per_exec > 100000是强信号，尤其当rows_processed_per_exec远低于它（比如比值
用DBA_HIST_SQLSTAT筛出真问题SQL
AWR报告只给Top 30，且没带历史变化。想抓住反复出问题的SQL，必须查DBA_HIST_SQLSTAT，按周期聚合筛选：
- 执行这个查询（替换
&begin_snap和&end_snap）：SELECT sql_id, executions_delta, buffer_gets_delta, ROUND(buffer_gets_delta / NULLIF(executions_delta, 0), 0) gets_per_exec FROM dba_hist_sqlstat WHERE snap_id BETWEEN &begin_snap AND &end_snap AND executions_delta > 10 AND buffer_gets_delta > 1000000 ORDER BY gets_per_exec DESC;
- 重点过滤条件：
executions_delta > 10排除偶然执行的噪音；buffer_gets_delta > 1000000确保总量可观；再按gets_per_exec排序，不是总buffer_gets - 别漏掉
plan_hash_value字段：同一sql_id在不同快照里plan_hash_value变了，说明执行计划漂移，逻辑读暴增很可能源于此
为什么逻辑读高但CPU不高？先查等待事件
高buffer_gets但低cpu_time，说明时间没花在计算上，而是卡在等待——这时候优化SQL本身可能无效，得看它在等什么。
- 查
DBA_HIST_SQLSTAT里的iowait_time_delta和clwait_time_delta：前者突增说明I/O慢（如存储响应延迟），后者飙升可能是分布式事务或物化视图刷新拖慢 - 结合
DBA_HIST_ACTIVE_SESS_HISTORY，按sql_id聚合event：SELECT event, COUNT(*) cnt FROM dba_hist_active_sess_history WHERE sql_id = 'xxx' AND sample_time > SYSDATE - 1/24 GROUP BY event ORDER BY cnt DESC;
如果db file sequential read或latch: cache buffers chains占主导，问题在I/O或争用，不是SQL写法 -
buffer_gets高 +physical_reads也高 → 真实I/O压力；buffer_gets高 +physical_reads低 → 缓存命中好，但逻辑路径太绕，优先查执行计划
拿到SQL后怎么验证是不是真瓶颈
查到sql_id只是开始，下一步必须确认它是否真在拖慢业务，而不是“看起来很忙”。
- 用
awrsqrpt.sql生成单SQL报告（不是整库AWR），重点关注“SQL Plan Monitoring Details”里的A-Rows（实际返回行）和Starts（执行次数）比值：如果A-Rows是100，Starts是10000，说明循环执行了10000次才凑够100行，明显驱动不当 - 对比
v$sql_plan_statistics_all里的buffer_gets和disk_reads：若disk_reads占比超过5%，且buffer_gets已超10万，说明缓存失效频繁，可能跟db_cache_size配置或热点数据分布有关 - 检查绑定变量：同
sql_id下child_number多（查v$sql），且各child的buffer_gets差异大，大概率是绑定变量窥探+直方图导致计划分裂，得看peeked_binds是否匹配谓词选择性
真实场景里，最常被忽略的是：逻辑读高的SQL，往往不是单条语句写得差，而是被高频调用的PL/SQL过程反复执行——它不会出现在“SQL ordered by Gets”里，但它的子SQL会。所以看到可疑SQL，顺手查DBA_HIST_ACTIVE_SESS_HISTORY里的plsql_entry_object_id，才能闭环定位。
