oracle索引碎片率需通过analyze index validate structure后查index_stats中del_lf_rows/lf_rows比值，>20%且height>4、聚簇因子异常时才建议重建。
直接看 INDEX_STATS 的 del_lf_rows / lf_rows 比值
Oracle 不提供“碎片率”字段，必须先触发结构校验，再查即时视图 INDEX_STATS。这个视图只在当前会话有效、单行、且被后续 ANALYZE 覆盖——不是查不到，是根本没存进去。常见错误包括：加了 ONLINE（VALIDATE STRUCTURE ONLINE 不支持）、跨会话查询、或中间执行了其他 ANALYZE 导致上一条结果被冲掉。
实操建议用最小闭环组合：
ANALYZE INDEX scott.pk_emp VALIDATE STRUCTURE; SELECT name, height, blevel, lf_rows, del_lf_rows, ROUND(del_lf_rows / NULLIF(lf_rows, 0) * 100, 2) AS frag_pct FROM index_stats;
注意：lf_rows 是当前叶块中有效行数，del_lf_rows 是已删除但未复用的叶行数。比值 > 20% 是空间回收的关键阈值，但不能单独看——它只说明“有空间可收”，不等于“必须立刻重建”。
交叉验证 HEIGHT 和 CLUSTERING_FACTOR 异常是否同步发生
单个指标容易误判。真正需要重建的空间型场景，往往三者共现：
-
del_lf_rows / lf_rows > 20%：说明大量叶块空间空置，物理上存在可回收空间 -
HEIGHT > 4（即BLEVEL > 3）：B 树层级过深，每次索引扫描要多读 1–2 层块，不仅浪费 I/O，还放大碎片影响 -
AVG_DATA_BLOCKS_PER_KEY显著大于NUM_ROWS / DISTINCT_KEYS：聚簇因子膨胀，意味着相同键值的数据物理离散，范围扫描时不得不跳着读块，进一步加剧空间利用率低下
其中 HEIGHT 来自 INDEX_STATS，是即时结构检查结果；而 DBA_INDEXES.BLEVEL 是统计信息快照，可能滞后。所以判断空间回收必要性时，优先信 HEIGHT。
ALTER INDEX ... REBUILD 前必须确认归档与锁行为
重建不是“删旧建新”的原子操作，尤其在 OLTP 环境下，空间回收代价可能远超预期：
-
REBUILD ONLINE仍会持 SSX 锁，阻塞其他 DDL；原索引继续生成 undo/redo，归档日志可能瞬间暴涨 - 若原索引上有长事务未提交，重建会卡在
WAITING FOR ONLINE INDEX BUILD，KILL SESSION不一定立即生效 -
NOLOGGING能省 redo，但该索引段从此无法通过归档恢复——生产环境除非有完整备份+可接受 RPO，否则慎用 - 重建后必须立刻执行
DBMS_STATS.GATHER_INDEX_STATS，否则 CBO 仍用旧的CLUSTERING_FACTOR，执行计划可能劣化
真正想回收空间，别只盯着 REBUILD。如果表本身高水位严重（比如 blocks * 8 / 1024 远大于 num_rows * avg_row_len / 1024 / 1024），先收缩表或 MOVE 分区，再重建索引，效果更彻底。
别忽略 DBA_SEGMENTS 中的 BYTES 与实际使用偏差
索引段空间是否真能回收，最终得看 DBA_SEGMENTS.BYTES 是否下降。但要注意：即使 frag_pct 高、HEIGHT 大，重建后 BYTES 未必明显减少——因为 Oracle 默认按 extent 分配，小索引重建前后可能都在同一个 extent 内，只是内部块重组了。
真正释放空间的信号是：DBA_SEGMENTS.BLOCKS 下降，且对应表空间的空闲块数上升。这通常发生在索引原本跨多个 extent、重建后成功合并为更少 extent 的情况。所以判断“空间回收是否成功”，必须查 DBA_SEGMENTS，而不是只信 INDEX_STATS 里的计算值。
