对分区索引执行analyze index validate structure会报ora-02243错误，因其不支持分区索引；需按局部索引（逐分区分析）或全局索引（整索引分析）分别处理，并用del_lf_rows/lf_rows计算碎片率，≥20%才需干预。
analyze index validate structure 对分区索引无效
直接对分区索引（如 ind_obj_id）执行 analyze index index_name validate structure 会报错 ora-02243: alter index or alter materialized view option not allowed —— 因为该命令不支持分区索引对象。你看到的“成功分析”结果，其实是误操作后查了 index_stats，但该视图只反映最后一次 analyze 的单个索引（非分区）快照，对分区索引无意义。
查分区索引碎片必须按子分区或局部索引段逐个分析
分区索引分两类：局部索引（LOCAL）和全局索引（GLOBAL）。前者每个分区对应一个独立索引段，后者是统一管理的单一段。碎片必须落到具体段上评估：
- 局部索引：需遍历
dba_ind_partitions，对每个partition_name单独执行ANALYZE INDEX schema.index_name PARTITION(partition_name) VALIDATE STRUCTURE - 全局索引：可直接用
ANALYZE INDEX global_index_name VALIDATE STRUCTURE，但注意它锁的是整个索引，不是单个分区 - 执行前确认用户有
ANALYZE ANY INDEX或对应索引的ANALYZE权限，否则报ORA-01031: insufficient privileges
查完之后怎么算碎片率？盯紧 del_lf_rows / lf_rows
ANALYZE ... VALIDATE STRUCTURE 后，立即查 index_stats 视图，关键字段只有三个：del_lf_rows（已删除叶行数）、lf_rows（当前叶行总数）、height（B树高度）。碎片率公式固定为：
ROUND((del_lf_rows / NULLIF(lf_rows, 0)) * 100, 2) AS "碎片率(%)"
注意：
-
NULLIF(lf_rows, 0)防止除零；lf_rows为 0 表示该分区索引段为空，无需处理 - 碎片率 ≥ 20% 才真值得干预；
height ≥ 4且碎片率 > 10% 时，重建比合并更有效 - 别信
del_lf_rows_len / lf_rows_len—— 这个值受行长度变化干扰大，Oracle 官方推荐用行数比
真正影响性能的是空叶块，不是碎片率数字本身
碎片率高只是表象，底层问题是删除后留下的空叶块（empty leaf blocks）仍被 INDEX FAST FULL SCAN 或 INDEX RANGE SCAN 扫描。这些块占内存、增 IO，但 ANALYZE 不告诉你哪些块是空的。要定位它们，得结合：
-
DBMS_SPACE.SPACE_USAGE查具体分区段的fs1_blocks~fs4_blocks（不同空闲度块数） - 对比
leaf_blocks和实际有效叶块数（lf_rows/ 平均键长估算），差值大说明空块多 - 如果某分区
del_lf_rows = lf_rows，意味着所有叶行都被删过一遍——这分区基本就是“空壳”，直接DROP INDEX PARTITION更干脆
别在没验证空块分布前就盲目重建；一次重建可能把原本连续的物理存储打散成更碎的 extent。
