如果是OLTP系统，存在正大量的删除和更新操作的系统中，日积月累，索引将会千疮百孔，使用索引用来检索数据的效率会急转直下。因此要求我们定期的对索引进行维护，我们可以使用DROP/CREATE方式或REBUILD方式完成索引的重建，恢复索引应该有的效率。
问题来了，什么时候需要重建？重建索引的依据是什么呢？
有两个依据可供参考。第一个是，查看索引的“高度”，如果索引树高超过了4我们就需要重点关注；另外一个参考依据是，索引条目被删除的数据占总索引条目的百分比如果超过了20%，一般在这种情况下就要考虑重建索引。
如果获得这两个参考依据？方法其实很简单，我们仅需对索引进行一下分析，然后通过INDEX_STATS视图辅助分析即可。拿一个具体的例子看一下。
1.分析索引
nt5beijing@bidb> analyze index SALES_INFO_IDX validate structure;
Index analyzed.
2.得出重建索引的判断依据
nt5beijing@bidb> select HEIGHT,(DEL_LF_ROWS/LF_ROWS)*100 from index_stats;
HEIGHT (DEL_LF_ROWS/LF_ROWS)*100 4 .312030747
通过这样一条简单的SQL语句便可以给出我们两条重要的重建卖手机号码平台索引的依据。
3.根据上面的统计结果有何结论？重建索引？不重建索引？
答案是：不一定！
重建的理由：此处我们看到，该索引的高度已经突破了4，可以考虑重新创建一下该索引。
不重建的理由：从删除的索引叶子的数据与索引叶子总条数的比例上看远远的小于20%，此时不到1%。
这种现象多见于数据仓库类系统。需要酌情对此类索引进行调整。
4.关于INDEX_STATS的参考
请参考《【索引】使用索引分析快速得到索引的基本信息》
5.小结
本文并没有给出索引重建的金科玉律，没有一成不变的法则，一切都是参考信息，具体定夺的人是自己。
在生产环境中如果考虑对索引进行维护，往往考虑的因素很多，在这些参考依据的基础上还要考虑是否有充足的维护窗口，是否可以容忍在索引维护期间系统出现的锁等待问题。是采用DROP/CREATE方式还是REBUILD方式也要具体场景具体分析。
Good luck.
secooler
10.06.30
-- The End --
