索引缺失最直接表现是大量物理读，需通过AWR中“SQL ordered by Physical Reads”定位高物理读SQL，结合执行计划验证是否全表扫描，并用DBA_HIST_SEG_STAT确认热点表及索引使用情况。
查“SQL ordered by Physical Reads”确认真实IO压力源
索引缺失最直接的表现是大量物理读——数据库被迫从磁盘逐块读取数据，而不是走索引快速定位。awr报告里sql ordered by physical reads页才是关键入口，不是sql ordered by gets（逻辑读高可能是缓存好，不等于慢）。
重点关注单条SQL的Physical Reads值：在OLTP系统中，超过10万次/执行基本可判定为严重缺失索引；若该SQL同时出现在Top 5 Timed Foreground Events的db file sequential read前列，就几乎坐实了索引问题。
- 别只看排序靠前的SQL——有些低频但单次物理读极高的SQL，可能正是批量作业或报表触发的“定时炸弹”
- 注意对比
Executions和Physical Reads比值：如果执行次数少但单次物理读爆炸（比如1次执行读50万块），优先检查WHERE条件是否全表扫描 - RAC环境下必须核对
Instance ID，避免把节点A的高物理读误判为全局问题
结合Execution Plan验证索引是否被真正使用
拿到可疑SQL的SQL_ID后，不能只信AWR里的统计值，必须查它实际用的执行计划。用DBA_HIST_SQL_PLAN视图回溯历史计划，命令如下：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', NULL, NULL, 'TYPICAL'));重点看Operation列是否出现FULL TABLE SCAN，以及Object_Name是否指向目标表而非索引。如果计划显示走了索引但性能仍差，大概率是索引选择性低或统计信息过期——这时要跳到下一步。
- 如果
DBA_HIST_SQL_PLAN查不到记录，说明该SQL未被AWR捕获（可能因_cursor_plan_unload_time参数或共享池老化），改用v$sql_plan查当前缓存计划 - 11g默认启用自适应游标共享（ACS），同一
SQL_ID可能对应多个子游标（CHILD_NUMBER），务必用DBA_HIST_SQLSTAT确认哪个子游标贡献了高物理读 - 执行计划里出现
INDEX RANGE SCAN但Rows预估远低于实际，往往是列统计信息不准，不是索引本身问题
用DBA_HIST_SEG_STAT确认索引列访问模式
索引缺失常伴随“不该扫的表被反复扫”。通过DBA_HIST_SEG_STAT查对象级IO分布，能绕过SQL粒度，直接定位热点表：
SELECT owner, object_name, object_type, physical_reads FROM dba_hist_seg_stat s JOIN dba_hist_snapshot sn ON s.snap_id = sn.snap_id WHERE sn.begin_interval_time > SYSDATE - 1 AND object_type = 'TABLE' ORDER BY physical_reads DESC FETCH FIRST 5 ROWS ONLY;
如果某张表physical_reads异常高，而它的主键/常用查询字段没有对应索引，就是典型缺失场景。尤其注意object_name带$后缀的IOT溢出段或LOB段——这些地方容易被忽略，但物理读飙升时往往藏在这里。
-
DBA_HIST_SEG_STAT默认只保留最近7天数据，若问题发生在更早时间，需确认retention参数是否被调小（查dba_hist_wr_control） - 区分
physical_reads和logical_reads：前者代表真·磁盘压力，后者高可能只是缓存没命中，不必然需要建索引 - 对分区表，
object_name显示的是分区名而非基表名，需关联dba_tab_partitions反查归属
警惕11g特有的索引失效陷阱
Oracle 11g引入了函数索引、虚拟列索引等新特性，但也带来几类隐蔽的索引失效场景，AWR不会直接报错，但物理读会无声暴涨：
- 查询条件对索引列用了函数，比如
WHERE UPPER(name) = 'JOHN'——即使建了UPPER(name)函数索引，绑定变量窥探失败时也可能退化为全表扫描 - 隐式类型转换：
WHERE order_id = '12345'（order_id是NUMBER），导致索引失效，AWR里看到的就是全表扫描+高物理读 - LIKE条件写成
LIKE '%abc'——B-Tree索引完全无效，但执行计划可能仍显示INDEX RANGE SCAN（骗人），实际走的是索引全扫 - 统计信息陈旧：11g默认自动收集，但若表被大量DML后未触发自动更新（如
STALE_PERCENT未达阈值），优化器可能选错计划
这类问题在AWR里表现为：SQL物理读高、执行计划看似合理、但DBA_HIST_SQLSTAT中buffer_gets_per_exec和disk_reads_per_exec比值严重失衡——这时候得翻v$sql的is_bind_sensitive和is_shareable字段，确认是否存在游标分裂。
