不能直接当性能根因看，因物理读高可能是合理行为（如报表扫描），需结合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 排名，本质是“总量榜单”，不是“压力热力图”。
