不能只看STATUS字段，VALID仅表示索引物理完好；需结合v$object_usage的USED列、AWR中执行计划（INDEX RANGE SCAN/ TABLE ACCESS FULL对比）及SQL谓词写法（如缺失前置列、函数操作、隐式转换）综合判断是否真正生效。
查索引状态不能只看 STATUS 字段
很多人一上来就跑 select status from user_indexes where index_name = 'xxx'，看到 valid 就以为索引“好好的”。其实这只能说明索引物理结构没损坏，完全不等于它被 sql 用上了。oracle 优化器是否选它，取决于统计信息、谓词写法、数据分布、执行计划路径等一堆动态因素。
真正要判断“无效”，得看两点：一是该索引在业务高峰期是否被任何 SQL 实际命中；二是有没有长期处于 UNUSED 或 MONITORING 状态但 USED = 'NO' 的记录。
所以第一步不是查状态，而是先开监控：
ALTER INDEX your_index_name MONITORING USAGE;- 等至少一个业务高峰周期（比如 24 小时或一次大促窗口）
- 再查
SELECT * FROM v$object_usage WHERE index_name = 'YOUR_INDEX_NAME';，重点看USED列是不是YES
从 AWR 报告里定位“本该走索引却没走”的 SQL
AWR 本身不直接告诉你某条 SQL 用了哪个索引，但它能暴露线索：Top SQL 列表里的高逻辑读、高 CPU 消耗语句，如果同时伴随 db file sequential read 等待事件比例异常低，反而 db file scattered read 或 direct path read 占比高，大概率是走了全表扫描（FTS）而不是索引访问。
更关键的是结合 AWR 中的 SQL 统计和执行计划快照：
- 在 AWR 报告的 “SQL ordered by Gets” 或 “SQL ordered by Executions” 部分，找到可疑 SQL 的
SQL_ID - 用
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id'));查它最近几次的历史执行计划 - 重点对比：同一 SQL_ID 下不同快照中，
ACCESS_PREDICATES和FILTER_PREDICATES是否变化；OPERATION是INDEX RANGE SCAN还是TABLE ACCESS FULL - 如果某次快照突然从索引扫变成全表扫，再查那段时间的
v$segment_statistics，看对应表的logical reads是否暴增，基本可锁定是统计信息过期或绑定变量窥探导致计划劣化
常见“看似有效、实则失效”的索引场景
有些索引在 DDL 层面一切正常，但业务 SQL 根本不会触发它。这类“幽灵索引”最容易被忽略：
- 复合索引
(A, B, C)，但查询只写了WHERE B = ? AND C = ?—— 缺少前置列A，优化器无法使用 - 索引列上用了函数，比如
WHERE UPPER(name) = 'ABC'，除非建了函数索引，否则原索引失效 - 字段是
VARCHAR2，但查询条件漏了引号：WHERE status = 1（status 是字符串），隐式转换让索引失效 - 用
NOT IN、!=或LIKE '%abc'，优化器估算返回行数太多，主动放弃索引 - 表很小（比如几百行），优化器认为 FTS 比索引 + 回表更快，直接跳过索引
重建索引前务必确认是否真有必要
ALTER INDEX ... REBUILD ONLINE 不是万能解药。它只解决物理碎片或 STATUS = UNUSABLE 的问题，对“逻辑上不被使用”的索引毫无帮助。反而可能引发短暂锁、增加 I/O 压力、甚至因重建后统计信息重置导致计划突变。
真正该做的顺序是：
- 先确认该索引是否真被业务 SQL 需要（查
v$object_usage+ AWR 中关联 SQL 的执行计划） - 再检查对应表的统计信息是否最新（
LAST_ANALYZED时间、NUM_ROWS是否合理） - 最后看是否有写法问题（函数、类型不匹配、缺失前置列等）
- 只有当以上都排除，且索引确实出现
UNUSABLE或严重块分裂（HEIGHT > 4、BLEVEL异常高），才考虑重建
最常被跳过的一步，是没验证重建后 SQL 是否真的开始用这个索引——重建完立刻查 DBMS_XPLAN.DISPLAY_CURSOR，别只看 DDL 成功了就收工。
