物理读高是索引缺失最硬证据，单次执行超10万且执行次数少基本坐实；需查AWR中DBA_HIST_SQL_PLAN确认是否全表扫描，或用DBA_HIST_SEG_STAT定位热点表及外键索引缺口。
直接看“SQL ordered by Physical Reads”，不是逻辑读，不是执行时间，就是物理读。 索引缺失最硬的证据是数据库被迫反复从磁盘读块——AWR里这个指标不会骗人。
为什么Physical Reads高就大概率缺索引
全表扫描或低效索引访问会触发大量单块/多块物理读；而健康走索引的OLTP查询，单次执行物理读通常低于100次。如果某条SQL在AWR中显示单次执行Physical Reads > 100,000，且Executions不高（比如
- 别被
Buffer Gets（逻辑读）高迷惑：缓存命中好时逻辑读高≠慢，但物理读高一定意味着IO压力真实存在 - 对比
db file sequential read等待事件：若该SQL同时出现在Top 5 Timed Events中，且平均等待>10ms，索引问题几乎坐实 - RAC环境务必确认
Instance ID，避免把节点B的物理读误判为全局瓶颈
用DBA_HIST_SQL_PLAN验证执行路径
拿到高物理读SQL的SQL_ID后，必须查它历史实际用的执行计划，不能只信统计值。
- 运行：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('your_sql_id', NULL, NULL, 'TYPICAL')); - 重点盯
Operation列：出现FULL TABLE SCAN且Object_Name是目标表名（非索引名），就是缺索引铁证 - 若显示
INDEX RANGE SCAN但性能仍差，先检查Rows预估值是否远低于实际返回行数——这往往是列统计信息过期，不是索引本身问题 -
DBA_HIST_SQL_PLAN查不到？说明该SQL未被AWR捕获，改用v$sql_plan查当前缓存计划
绕过SQL粒度，直击热点表与索引使用盲区
有些SQL没进Top N，但背后表被反复扫。用DBA_HIST_SEG_STAT看对象级IO分布：
- 查
physical_reads_total最高的表，再反查它是否有被WHERE条件高频过滤的列建了索引 - 特别注意外键列：父表
DELETE或UPDATE时若子表外键列无索引，会引发enq: TM - contention，同时伴随子表的异常物理读 - 执行
SELECT语句确认外键索引状态时，注意user_ind_columns和user_cons_columns的position匹配，否则可能漏掉复合外键中的单列索引缺口
真正容易被忽略的是：AWR里Physical Reads高的SQL，其执行计划可能在不同子游标（CHILD_NUMBER）下完全不同。11g默认开启自适应游标共享（ACS），必须结合DBA_HIST_SQLSTAT确认哪个子游标贡献了高物理读——否则你优化的可能是另一个子游标的计划。
