1。重建指标的原因
A和Oracle的B树索引随着时间的推移变得不平衡（被误解）
b，索引片段正在增加。
c，索引在增加，删除的空间不能重用。
索引聚类因子（簇因子）不同步，可以重建和修复（被误解）。
2。重构索引的本质
本质：重构索引首先在数据库中执行删除操作，然后执行插入操作。
三.反对重建索引的理由
大多数的脚本依赖于index_stats动态表。这个表充满了下面的命令：
分析指标…验证结构；
虽然这是一个有效的指标的考核方法，得出独家表锁时，分析指标，大指标的DML操作的影响，这期间不允许。
虽然这种方法可以在不锁定表的情况下在线运行，但可能需要额外的时间。
重建指数的直接结果是重做活动可能会增加，整个系统负载也可能得到改善。
插入/更新/删除操作导致索引的连续发展和索引的分割和增长。
重建索引后，连接更加紧密。然而，作为表继续执行DML操作，必须指数直到指数达到平衡。
结果，重做活动增加了，索引分割更可能直接影响性能，因为我们需要更多的I/O、CPU等用于索引重建。
一段时间后，该指数可能再次遇到问题，因此它可能被重新标记为一个重建，从而陷入恶性循环。
因此，通常最好保持指数处于自然平衡状态，或者至少要防止指数的定期重建。
4，甲骨文的最后建议
一般来说，B树索引几乎没有必要重建，其基本原因是B树索引在很大程度上可以自我管理或自我平衡。
大多数索引是平衡和完整的，因为自由叶条目可以重用。
插入/更新和删除操作确实会使索引块周围的可用空间形成碎片，但一般来说，这些片段是正确重用的。
聚类因子聚类因子反映了与给定索引键值对应的表中的数据排序，重建索引不影响聚类因子，聚类因子只能通过重组表的数据来改变。
强烈建议不定期重建该指数，但应使用适当的诊断工具。
个人的结论是，如果重建指数的大量工作是对应于一个小的收入，那就不值得损失，如果系统有空闲时间，重建前后的结果表明性能得到改善，值得重建。
5，改进方法
索引合并通常是优先考虑的，而不是重建索引：
a，不需要占用近2磁盘存储空间的空间
B，可以在线操作
c，不需要重建索引结构，但要尽快使用索引叶块，这样可以避免过多的系统开销。
6。重建指数的真正需要
索引或索引分区因介质故障而受到损坏。
一个索引标记为unusabel需要重建
索引移动到一个新的表空间，或者需要更改一些存储参数。
将数据通过SQL加载程序加载到表分区后，需要重新构建索引分区。
重建索引以启用键压缩
位图索引与B树索引本质上不同，这意味着重建。
