awr报告不直接显示表空间碎片率，但可通过db file sequential read等待异常升高（占比>20%、av rd(ms)>15ms）、physical read io requests增幅远超physical reads、以及索引扫描退化为全表扫描这三者交叉验证碎片导致i/o离散化。
awr报告本身不直接显示表空间碎片率，但能通过i/o行为异常反向锁定碎片是否正在拖慢扫描性能。 关键不是找“碎片”这个词，而是看物理读是否在不合理地变多、变慢、变散。
查db file sequential read等待是否异常升高
这是最直接的信号。碎片严重时，索引范围扫描或小表访问被迫跳着读多个不连续块，单块读等待必然拉长：
- 在AWR的“Top 5 Timed Events”里，
db file sequential read占比超过20%且Av Rd(ms) > 15ms，就要警觉 - 对比正常时段报告：若该事件平均等待时间翻倍，而SQL执行计划没变、Buffer Hit %下降超5%，大概率是碎片导致I/O离散化
- 排除干扰项：归档写、RMAN备份、LOB操作也会抬高该等待，需结合“SQL ordered by Physical Reads”确认是否集中在业务表和索引段
看Tablespace IO Stats中I/O请求次数 vs 物理读块数
碎片会让一次逻辑读被迫拆成多次I/O请求——这不是缓存问题，是磁盘布局问题：
- 在“Tablespace IO Stats”章节，重点对比两个指标：
physical read IO requests和physical reads - 若前者增幅远超后者（比如IO请求+80%，但物理读只+20%），说明每次I/O读取的块数下降，典型碎片特征
- 同时检查对应表空间的
Avg I/O Elapsed Time是否明显高于其他表空间，进一步佐证I/O效率恶化
交叉验证SQL ordered by Physical Reads中的全表扫描模式
碎片不会让索引“消失”，但会让优化器弃用它——因为扫描代价变得比全表还高：
- 找出PHYSICAL_READS排名靠前的SQL，用
DBMS_XPLAN.DISPLAY_AWR查其历史执行计划 - 若原本走
INDEX RANGE SCAN的SQL，近期突然变成TABLE ACCESS FULL，且CLUSTERING_FACTOR未变、统计信息也新鲜，那很可能是索引B树深度失衡或叶块离散，根源常在底层表空间碎片 - 特别注意那些关联了高I/O索引（OBJECT_NAME含
INDEX）但执行计划却走全表的SQL，它们是碎片影响扫描性能的“活证据”
真正难判断的点在于：碎片和统计信息过期、数据倾斜、绑定变量窥探失效等现象会共现。不要只盯一个指标，必须把db file sequential read等待、physical read IO requests增幅、执行计划退化这三者串起来看——缺一不可。否则容易把本该加索引的问题，误判成要整理表空间。
