潛水珽的異想世界

在Oracle資料庫中,有關於重建索引是否對效能有所幫助，已經進行了許多的討論。一般來說，需要重建b-tree索引的場景非常少，主要是因為b-tree 索引很大程度上是自我管理或自我平衡的。

重建索引的最常見理由是：

-索引變得碎片化
-索引不斷增長-刪除空間不被重複使用
-索引聚簇因子變得不同步

實際上，大多數索引都保持平衡且無碎片，因為free leaf的空白內容將被重用。插入/更新和刪除會導致空閒插槽分散在索引塊周圍，但是通常會重新填充這些空閒插槽。
聚類因子反映了表數據相對於給定索引鍵的排序方式。重建索引永遠不會影響聚類因素，而是需要重新組織表。

其次，重建索引的影響可能非常重大，請仔細閱讀以下註釋：

大多數腳本依賴於index_stats動態表。通過以下命令填充：

語法: analyze index ... validate structure;

儘管這是檢查索引的有效方法，但它在分析索引時會獲取排他表鎖。特別是對於大索引，這可能會非常引人注目，因為在此期間不允許對錶進行DML操作。儘管可以在不考慮鎖定的情況下聯機運行它，但它可能會花費額外的時間。 

重做活動可能會因重建索引而直接增加，並且可能會影響總體性能。

插入/更新/刪除會導致索引隨著索引的分裂和增長而隨著時間發展。重建索引時，可以使它變得更加緊湊。但是，隨著DML操作繼續在表上進行，必須再次重做索引拆分，直到索引達到其平衡為止。結果，隨著我們消耗更多的I / O，CPU等來服務於索引重組，重做活動增加，索引拆分現在更可能直接影響性能。一段時間後，索引可能再次遇到“問題”，並可能被重新標記以進行重建，從而導致惡性循環繼續。因此，通常最好使索引保持其自然平衡和/或至少防止定期重建索引。

通常首選索引合併，而不是重建索引。具有以下優點：

-不需要大約兩倍於磁盤存儲空間
-始終在線
-不會重組索引，而是盡可能合併索引葉子塊，避免了第2點中所述的系統開銷。

由於上述原因，強烈建議不要定期重建索引，而應使用適當的診斷程序。

請參閱以下說明，其中列出了可用於分析索引結構的腳本。它不使用“分析索引驗證結構”命令，而是基於當前表和索引統計信息來估計索引大小。

Ref:

Note 989186.1 - Script to investigate a b-tree index structure