生产环境是否需对频繁在索引列上进行dml语句进行rebuild？

所以对于1来说
当插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。

重建索引后，它将连接的更为紧凑；但是，随着对表不断执行 DML 操作，必须再次分割索引，直到索引达到平衡为止。

结果，重做活动增加，且索引分割更有可能对性能产生直接影响，因为我们需要将更多的 I/O、CPU 等用于索引重建。

经过一段时间后，索引可能会再次遇到“问题”，因此可能会再被标记为重建，从而陷入恶性循环。

因此，通常最好是让索引处于自然平衡和（或）至少要防止定期重建索引。
所以我认为极少需要重建 B 树索引，基本原因是 B 树索引很大程度上可以自我管理或自我平衡。收起

可能真正需要重建索引的情形也不是太多 以下是一些常见的：
索引或索引分区因介质故障损坏
标记为UNUSABEL的索引需要重建
索引移动到新的表空间或需要改变某些存储参数
通过SQL*Loader加载数据到表分区后，需要重建索引分区
重建索引以启用键压缩
位图索引本质不同于B树索引，建议重建

但也并不是只有这些时候才去重建，如果重建索引的巨大工作量与之对应的是极小的收益，那就得不偿失。如果系统有可用空闲期，重建之前和之后的测量结果表明性能有提高，值得重建。收起

对于2 3
N久以前Oracle建议我们定期重建那些高度为4，已删除的索引条目至少占有现有索引条目总数的20%的这些表上的索引。但Oracle现在强烈建议不要定期重建索引。
通常是优先考虑index coalesce（索引合并），而不是重建索引。索引合并有如下优点：
不需要占用近磁盘存储空间 2 倍的空间
可以在线操作
无需重建索引结构，而是尽快地合并索引叶块，这样可避免系统开销过大。

至于是不是真有有必要 我们可以用analyze index ... validate structure;来看index_stats 动态表。分析一下如果真的已删除的索引条目占有现有索引条目总数的百分比很高的时候可以去自己权衡。没有永远的不好 也没有永远的会好收起

然后对于4
Clustering factor群集因子反映了给定的索引键值所对应的表中的数据排序情况。重建索引不会对群集因子产生影响，集群因子只能通过重组表的数据改变。收起

我认为去rebuild索引是要有理由的
大家一般会想当 1.oracle的B树索引随着时间的推移变得不平衡 2.索引碎片在不断增加3.索引不断增加，删除的空间没有重复使用4.索引 clustering factor （集群因子）不同步，可以通过重建修复

但重建索引的本质是：重建索引在数据库内部是先执行删除操作，再执行插入操作。所以对于 1 4 重建根本没有任何用。收起

最简单的方法，就是观察index的segment大小，如果列和表相差很多，但是segment相差不大了，考虑重建。

还有就是一次性大量dml操作数据库，或者你们的业务规则是导致数据发生不均衡，例如你们按照时间大量插入数据，然后又大量删除历史时间，这样可能导致时间列的index数据分布不均，可以考虑重建收起

没有必要频繁做rebuild的，有碎片的时候再重建收起