sql ordered by reads 本质是sql文本哈希聚合后的总逻辑读（buffer gets）汇总，混计表、索引、lob等所有段的读取，无法区分索引使用情况，定位高热度索引应查segments by logical reads中object_type='index'的行。
SQL ordered by Reads 本质是总逻辑读汇总，不是索引使用统计
这个页面列的是 SQL 文本哈希聚合后的 Buffer Gets（逻辑读）总量，但它把表、索引、LOB、临时段的读全部混在一起算。比如一条走 INDEX RANGE SCAN + TABLE ACCESS BY INDEX ROWID 的语句，它的逻辑读会同时计入索引段和表段，但报告里只归在 SQL 行上——你根本看不到哪个索引被读了多少次。
常见错误现象：SQL ordered by Reads 排第一的 SQL 看似热点，结果发现它用的是高效索引，真正反复扫同一低效索引的 SQL 却没上榜；或者同逻辑不同字面量（硬编码 vs 绑定变量）被拆成多行，掩盖真实调用量。
-
Buffer Gets在 Oracle 11g 中是估算值，尤其带并行或绑定变量时，和实际段级逻辑读常差 2–5 倍 - 默认只显示 top 30，且按 SQL 文本哈希聚合，无法反映真实执行频次
- 它不区分对象类型，不能替代
Segments by Logical Reads定位高热度索引
真正定位高热度索引，必须跳转到 Segments by Logical Reads
想确认哪个索引被频繁访问，唯一可靠路径是翻到 AWR 报告里的 Segments by Logical Reads 部分，筛选 OBJECT_TYPE = 'INDEX' 的行。这才是索引真实被访问强度的代理指标。
实操建议：
- 优先过滤
Owner列为业务 Schema（如SCOTT、HR），排除SYS、SYSTEM下的系统索引干扰 - 看
Logical Reads绝对值，而非%Total：一个索引读 500 万块，即使只占 DB 总逻辑读 0.3%，也远比读 50 万块但占 5% 的索引更值得查 - 对比同一索引在相邻快照中的读数：若从 200 万 → 800 万，且无应用发布，大概率是执行计划退化或统计信息失效
- 用
Object Name去DBA_OBJECTS查OBJECT_ID，再关联DBA_HIST_SEG_STAT看小时级波动，避开快照间隔不均导致的误判
验证“高热度”是否等于“低效使用”，得交叉三件事
逻辑读高 ≠ 索引用得好。必须验证以下三点：
- 若该索引的
Logical Reads> 对应基表Logical Reads × 1.5，且没大量排序/位图操作，说明回表严重，可能需要覆盖索引 - 进
SQL ordered by Gets页面，用Ctrl+F搜该索引名（如ORDERS_IDX_STATUS）：如果搜不到任何 SQL，说明这些逻辑读来自全表扫描（即索引存在但未被使用） - 运行
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id', NULL, NULL, 'ADVANCED'))，检查历史执行计划中是否真出现INDEX RANGE SCAN或类似索引访问路径
别忽略 Physical Reads 和 UnOptimized Reads 的区别
SQL ordered by Physical Reads 和 SQL ordered by Physical Reads (UnOptimized) 看似相似，但度量维度不同：
- 前者统计读取的数据块数（
blocks），后者统计 I/O 请求次数（requests） - 若数据库启用了 Smart Flash Cache，
UnOptimized Read Reqs只代表没命中缓存的请求；没启用时二者数值相同，此时该列表就等价于物理读 Top SQL - 对比两者可估算平均每次 I/O 读多少块：若数值接近，说明是小块 I/O（如单行索引查找）；若后者远小于前者，说明有大块读（如全表扫描或 LOB 访问）
真正影响性能的是物理读的分布和模式，不是单纯看总数——同一物理读量，分散在 1000 次小 I/O 还是 10 次大 I/O，对存储压力完全不同。
