Index Leaf Blocks 值持续为0或极低，表明该索引在业务负载中未被优化器选中使用，是判断索引是否实际失效的关键指标；它反映索引叶块的逻辑读次数，而非仅物理完整性。
只查 status 是无效动作，valid 只代表索引没物理损坏，完全不说明它被 sql 用过。真正判断“失效”，得看它在业务负载里是否被访问、是否被优化器选中——而 index leaf blocks 这个 awr 统计项，恰恰是少数能间接反映索引活跃度的底层指标之一。
为什么 Index Leaf Blocks 值低或为 0 很可疑
这个统计来自 AWR 的 Segments by Logical Reads 或 Segments by Physical Reads 报告，对应 object_type = 'INDEX' 的段。它统计的是该索引的叶块（leaf block）被逻辑读取的次数。
- 如果一个非分区索引在连续多个快照中
Index Leaf Blocks都是0或极低（比如 - 注意：它不等于“索引扫描次数”，而是叶块被读的次数；一次
INDEX RANGE SCAN可能读几十个叶块，但一次INDEX UNIQUE SCAN通常只读 1–3 个 - 若该索引在
Segments by Buffer Busy Waits里排名高，但Index Leaf Blocks极低，更值得怀疑——等待发生在叶块，但没人去读，大概率是反向键索引或序列热点争用，而非查询使用
怎么在 AWR 报告里定位这个值
AWR 报告本身不直接标出 “Index Leaf Blocks” 字样，它藏在 Segment Statistics 的细分列里。你需要：
- 打开 AWR 报告 → 找到 “Segments by Logical Reads” 表格 → 确保勾选了 “Show SQL Statements” 和 “Show Indexes”（部分版本需手动开启）
- 筛选
Object Type列为INDEX的行 → 查看Logical Reads和Physical Reads两列数值 - 重点对比同一索引在不同快照窗口（比如早高峰 vs 深夜）的读数变化：如果某次快照后突然归零，再结合该索引对应 SQL 的执行计划切换，就是强失效信号
- 别只盯单个索引：把该索引名和其基表名一起搜，看基表的
Logical Reads是否同步飙升——如果是，大概率正在走全表扫描
Index Leaf Blocks 为什么不能单独作为判断依据
它只是辅助线索，不是铁证。原因很实在：
- 某些 SQL 走了
INDEX FAST FULL SCAN，它读的是索引的全部块（包括 branch + leaf），但 AWR 不会把它记进Index Leaf Blocks，而是算进Physical Reads总量，容易误判为“没用索引” - 复合索引只用了后缀列（如索引
(A,B,C)，SQL 写WHERE B = ?），优化器弃用它，但你仍可能看到少量Index Leaf Blocks——那是其他 SQL 或维护操作（如统计信息收集）触发的 - 如果索引列上有函数（
UPPER(name)），而你没建函数索引，那这个原索引的Index Leaf Blocks就是 0，但它在 DDL 层面仍是VALID - AWR 快照粒度是分钟级，短时高频但短暂的索引访问可能被平均掉，看不出峰值
真正要闭环验证，必须把 Index Leaf Blocks 和 v$object_usage.USED、DBMS_XPLAN.DISPLAY_AWR 的执行计划、以及谓词是否匹配最左前缀这三件事串起来看。漏掉任意一环，都可能把“没被用”错判成“坏了”，或者把“被绕过”当成“好好的”。
