为什么Oracle AWR中的SQL Ordered by Reads排名具有误导性？

不能直接当性能根因看，因物理读高可能是合理行为（如报表扫描），需结合Executions计算Physical Reads/Executions比值（>1000在OLTP中属异常），并验证执行计划、访问对象及ASH热力图才能准确定位真实瓶颈。

SQL Ordered by Reads 为什么不能直接当性能根因看

awr 报告里 “sql ordered by reads” 按总物理读（physical reads）降序排列，但这个排序本身不区分执行频次、数据量和业务场景——一条报表 sql 扫 10gb 历史数据，物理读高是合理的；而一条每秒执行 50 次的订单查询，每次只读几十行却频繁触发物理读，才是真正要命的问题。

Executions 和 Physical Reads 必须交叉验证

单看 Reads 数值会漏掉关键信号。真正该盯的是 Physical Reads / Executions 这个比值：

• Physical Reads / Executions > 1000 在 OLTP 系统中基本可判定为异常，大概率对应全表扫描且无有效过滤
• 执行次数 Executions = 1 但 Physical Reads > 500000，优先检查是否是定时批量作业，而非实时接口问题
• 同一 SQL_ID 在不同快照中 Executions 波动剧烈（比如从 1000 突降到 1），说明绑定变量值分布不均或统计信息过期，计划已失稳

Reads 高 ≠ SQL 写得差，得看执行计划和访问对象

物理读高可能是优化器主动选择的结果，也可能是底层对象出了问题：

• 查 DBMS_XPLAN.DISPLAY_AWR('<code>SQL_ID‘)，确认 TABLE ACCESS FULL 是否出现在大表上，且 filter_predicates 没有隐式类型转换
• 用 DBA_HIST_SEG_STAT 反查该 SQL 访问的具体对象：Physical Reads 集中在某张小表（如配置表、状态码表），大概率是缺主键/唯一索引，被迫全表扫描+ROWID定位
• 如果 Physical Reads 主要落在 TEMP 或 UNDOTBS1 文件，说明不是索引缺失，而是排序/哈希聚合溢出或事务太长导致 undo 段反复读写

容易被忽略的采样盲区

AWR 默认 60 分钟采一次，会平滑掉短时尖峰。比如某条 SQL 在 2 分钟内执行了 3000 次、每次物理读 200，总 Reads 只有 60 万，排不进 Top 10；但它可能正是造成 db file sequential read 等待飙升的元凶。

这时候必须切到 ASH 报告，按 SQL_ID + EVENT + SESSION_ID 聚合，才能暴露真实调用密度。AWR 的 Reads 排名，本质是“总量榜单”，不是“压力热力图”。