索引重建是一個(gè)爭(zhēng)論不休被不斷熱烈討論的議題。當(dāng)然Oracle官方也有自己的觀點(diǎn)，我們很多DBA也是遵循這一準(zhǔn)則來(lái)重建索引，那就是Oracle建議對(duì)于索引深度超過(guò)4級(jí)以及已刪除的索引條目至少占有現(xiàn)有索引條目總數(shù)的20% 這2種情形下需要重建索引。近來(lái)Oracle也提出了一些與之相反的觀點(diǎn)，就是強(qiáng)烈建議不要定期重建索引。本文是參考了1525787.1并進(jìn)行相應(yīng)描述。

1、重建索引的理由

a、Oracle的B樹索引隨著時(shí)間的推移變得不平衡(誤解)

b、索引碎片在不斷增加

c、索引不斷增加，刪除的空間沒有重復(fù)使用

d、索引 clustering factor （集群因子）不同步，可以通過(guò)重建修復(fù)(誤解)

2、重建索引的本質(zhì)

本質(zhì)：重建索引在數(shù)據(jù)庫(kù)內(nèi)部是先執(zhí)行刪除操作，再執(zhí)行插入操作。

3、反對(duì)重建索引的理由

a. 大多數(shù)腳本都依賴 index_stats 動(dòng)態(tài)表。此表使用以下命令填充：

analyze index ... validate structure;

盡管這是一種有效的索引檢查方法，但是它在分析索引時(shí)會(huì)獲取獨(dú)占表鎖。對(duì)于大型索引，其影響會(huì)是巨大的，因?yàn)樵诖似陂g不允許對(duì)表執(zhí)行DML 操作。

雖然該方法可以在不鎖表的情況下在線運(yùn)行，但是可能要消耗額外的時(shí)間。

b. 重建索引的直接結(jié)果是 REDO 活動(dòng)可能會(huì)增加，總體系統(tǒng)負(fù)載也可能會(huì)提高。

插入/更新/刪除操作會(huì)導(dǎo)致索引隨著索引的分割和增長(zhǎng)不斷發(fā)展。

重建索引后，它將連接的更為緊湊；但是，隨著對(duì)表不斷執(zhí)行 DML 操作，必須再次分割索引，直到索引達(dá)到平衡為止。

結(jié)果，重做活動(dòng)增加，且索引分割更有可能對(duì)性能產(chǎn)生直接影響，因?yàn)槲覀冃枰獙⒏嗟?I/O、CPU 等用于索引重建。

經(jīng)過(guò)一段時(shí)間后，索引可能會(huì)再次遇到“問(wèn)題”，因此可能會(huì)再被標(biāo)記為重建，從而陷入惡性循環(huán)。

因此，通常最好是讓索引處于自然平衡和（或）至少要防止定期重建索引。

4、Oracle的最終建議

一般而言，極少需要重建 B 樹索引，基本原因是 B 樹索引很大程度上可以自我管理或自我平衡。

大多數(shù)索引都能保持平衡和完整，因?yàn)榭臻e的葉條目可以重復(fù)使用。

插入/更新和刪除操作確實(shí)會(huì)導(dǎo)致索引塊周圍的可用空間形成碎片，但是一般來(lái)說(shuō)這些碎片都會(huì)被正確的重用。

Clustering factor群集因子反映了給定的索引鍵值所對(duì)應(yīng)的表中的數(shù)據(jù)排序情況。重建索引不會(huì)對(duì)群集因子產(chǎn)生影響，集群因子只能通過(guò)重組表的數(shù)據(jù)改變。

強(qiáng)烈建議不要定期重建索引，而應(yīng)使用合適的診斷工具。

個(gè)人結(jié)論，如果重建索引的巨大工作量與之對(duì)應(yīng)的是極小的收益，那就得不償失。如果系統(tǒng)有可用空閑期，重建之前和之后的測(cè)量結(jié)果表明性能有提高，值得重建。

5、改良方法

通常是優(yōu)先考慮index coalesce（索引合并），而不是重建索引。索引合并有如下優(yōu)點(diǎn)：

a、不需要占用近磁盤存儲(chǔ)空間 2 倍的空間

b、可以在線操作

c、無(wú)需重建索引結(jié)構(gòu)，而是盡快地合并索引葉塊，這樣可避免系統(tǒng)開銷過(guò)大。

6、真正需要重建索引的情形

索引或索引分區(qū)因介質(zhì)故障損壞

標(biāo)記為UNUSABEL的索引需要重建

索引移動(dòng)到新的表空間或需要改變某些存儲(chǔ)參數(shù)

通過(guò)SQL*Loader加載數(shù)據(jù)到表分區(qū)后，需要重建索引分區(qū)

重建索引以啟用鍵壓縮

位圖索引本質(zhì)不同于B樹索引，建議重建

更多信息請(qǐng)查看IT技術(shù)專欄