必须不加 ONLINE 才能查到碎片数据，加 ONLINE 后 INDEX_STATS 视图一定为空；有效操作是执行 ANALYZE INDEX ... VALIDATE STRUCTURE 后立即查 index_stats，且需注意权限、分区索引分治处理、碎片率计算防除零及多指标交叉验证。
ANALYZE INDEX VALIDATE STRUCTURE 必须不加 ONLINE 才能查到碎片数据
加 online 参数后，index_stats 视图一定为空——oracle 官方明确不支持在线模式下的结构校验。你执行 analyze index idx_name validate structure online 看似成功，但紧接着 select * from index_stats 返回空行，不是语法错，是设计限制。
真正有效的组合只有：ANALYZE INDEX scott.pk_emp VALIDATE STRUCTURE;
然后立刻在同一会话中查：SELECT name, lf_rows, del_lf_rows, height FROM index_stats;
- 该视图只保留最后一次
ANALYZE的单行结果，跨语句、跨会话、甚至中间执行一次其他ANALYZE都会覆盖 - 若索引正被 DML 修改（比如大量 DELETE），可能报
ORA-00054: resource busy，需换低峰期重试 - 用户必须有
ANALYZE ANY INDEX或对应索引的ANALYZE权限，否则报ORA-01031
分区索引不能直接 ANALYZE，必须按局部/全局类型分治
对分区索引（如 ind_obj_id）直接执行 ANALYZE INDEX index_name VALIDATE STRUCTURE 会报 ORA-02243：alter index option not allowed。这不是权限问题，是 Oracle 不支持对分区索引对象整体做结构校验。
正确做法取决于索引类型：
- 局部索引（LOCAL）：遍历 DBA_IND_PARTITIONS，对每个分区单独执行：ANALYZE INDEX schema.idx_name PARTITION(part_name) VALIDATE STRUCTURE;
- 全局索引（GLOBAL）：可整索引分析，但锁的是整个索引段，不是单个分区
- 局部索引的每个分区是一个独立索引段，碎片必须落到具体分区上评估
- 别信“成功执行了 ANALYZE 就代表有结果”——查
INDEX_STATS前务必确认你刚分析的是目标分区 - 全局索引重建影响大，局部索引可只 rebuild 单个分区，更可控
碎片率公式必须用 del_lf_rows / lf_rows，且要防除零
Oracle 不提供现成的 “碎片率” 字段，必须自己算。官方推荐且最稳定的是行数比：ROUND((del_lf_rows / NULLIF(lf_rows, 0)) * 100, 2) AS "碎片率(%)"
-
lf_rows = 0表示该索引段当前为空，无需处理；不加NULLIF会触发除零错误 - 别用
del_lf_rows_len / lf_rows_len—— 行长度变化干扰大，和真实空间浪费无关 - 碎片率 ≥ 20% 是干预阈值，但需结合
height ≥ 4或INDEX FAST FULL SCAN逻辑读异常升高一起看 -
INDEX_STATS中的height是即时结构检查结果，比DBA_INDEXES.blevel更准，但不可持久化
查完就重建？先看三个指标交叉验证，别只盯一个数字
单看碎片率容易误判。真正影响性能的是删除后留下的空叶块（empty leaf blocks），它们仍会被扫描，占内存、增 IO，但 ANALYZE 不告诉你哪些块是空的。
-
del_lf_rows / lf_rows > 20%：说明叶块中已删除行占比高，后续 INSERT 易引发分裂 -
height > 4或blevel > 3：B 树层级过深，每次查找多走 1–2 层块读 -
avg_data_blocks_per_key >> num_rows / distinct_keys：聚簇因子异常膨胀，范围扫描效率暴跌 - 重建后必须立刻执行
DBMS_STATS.GATHER_INDEX_STATS，否则 CBO 仍用旧的CLUSTERING_FACTOR，可能导致执行计划劣化
碎片率只是表象，底层问题是空叶块是否被实际访问。如果查询总走分区裁剪或绑定变量精准匹配，高碎片率也可能无感——得看真实负载，不是看数字。
