许多DBA在排查Oracle数据库性能瓶颈时，第一反应往往是查看AWR报告中是否出现“碎片”字眼——但Oracle并不会直接给出“表空间碎片率”的数值。不过别担心，这并不意味着我们无法判断。真正需要关注的是I/O行为上的三个异常信号：物理读的不合理增加、速度变慢以及分布散乱。只要掌握这三个交叉验证点，就能较为准确地判断表空间碎片是否拖累了扫描性能。
排查db file sequential read等待事件是否异常升高
这是最直接的预警信号。当碎片严重时，索引范围扫描或小表访问会被迫跳跃式读取多个不连续的数据块，单块读等待时间自然会被拉长。具体判断方法如下：
- 在AWR的“Top 5 Timed Events”中，如果
db file sequential read占比超过20%，且A v Rd(ms) > 15ms，就需要提高警惕了。 - 与正常时段报告对比：若该事件平均等待时间翻倍，而SQL执行计划保持不变、Buffer Hit %下降超过5%，那么很有可能是碎片导致了I/O离散化。
- 不过要排除干扰项——归档写、RMAN备份、LOB操作也会抬高这个等待值。因此还需要结合“SQL ordered by Physical Reads”来确认问题是否集中在业务表和索引段上。
分析Tablespace IO Stats中I/O请求次数与物理读块数的关系
碎片带来的一个典型现象是：一次逻辑读被迫拆分成多次I/O请求。这其实并非缓存问题，而是磁盘布局出现了问题。具体操作如下：
- 在“Tablespace IO Stats”章节，重点对比两个指标：
physical read IO requests和physical reads。 - 如果前者增幅远超后者（例如IO请求增加了80%，但物理读只增加了20%），说明每次I/O读取的块数在下降——这正是碎片的一个典型特征。
- 同时，检查对应表空间的
A vg I/O Elapsed Time是否明显高于其他表空间，以进一步佐证I/O效率是否在恶化。
交叉验证SQL ordered by Physical Reads中的全表扫描模式
碎片不会让索引“消失”，但会让优化器主动弃用索引——因为扫描代价变得比全表扫描还高。关键在于找出那些“本应走索引却改走全表”的SQL：
- 找出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增幅、执行计划退化这三者串联起来分析——缺一不可。否则很容易把本该加索引的问题，误判成需要整理表空间。
