Oracle創(chuàng)建索引選擇合適的可選項

導讀：有些新手在Oracle數(shù)據(jù)庫中創(chuàng)建索引時往往不會使用可選項。其實，有時候在合適的場合使用一些可選項，可以提高索引的創(chuàng)建速度。如為了大批量導入數(shù)據(jù)，我們往往會先取消索引其以提高插入的速度。然后等數(shù)據(jù)導入完畢后再重新創(chuàng)建索引。在這個過程中如果能夠采用一些可選項，則可以縮短索引創(chuàng)建的時間。在Oracle數(shù)據(jù)庫中提供了豐富的可選項。我們常用的可選項主要有以下這些。

可選項一：NOSORT，記錄排序可選項

默認情況下，在表中創(chuàng)建索引的時候，會對表中的記錄進行排序，排序成功后再創(chuàng)建索引。但是當記錄比較多的是，這個排序作業(yè)會占用比較多的時間，這也就增加了索引建立的時間(排序作業(yè)是在索引創(chuàng)建作業(yè)中完成)。有時候，我們導入數(shù)據(jù)的時候，如采用insert into 語句插入數(shù)據(jù)過程中同時采用Order by子句對索引字段進行了排序。此時如果在索引創(chuàng)建過程中再進行排序的話，就有點脫褲子放屁，多此一舉了。為此在重新創(chuàng)建索引時，如果表中的數(shù)據(jù)已經(jīng)排好序了(按索引字段排序)，那么在創(chuàng)建索引時就不需要為此重新排序。此時在創(chuàng)建索引時，數(shù)據(jù)庫管理員就可以使用NOSORT可選項，告訴數(shù)據(jù)庫系統(tǒng)不需要對表中當記錄進行重新排序了。

采用了這個選項之后，如果表中的記錄已經(jīng)按順序排列，那么在重新創(chuàng)建索引的時候，就不會重新排序，可以提高索引創(chuàng)建的時間，節(jié)省內(nèi)存中的排序緩存空間。相反，如果表中的記錄是不按索引關鍵字排序的話，那么此時采用NOSORT關鍵字的話，系統(tǒng)就會提示錯誤信息，并拒絕創(chuàng)建索引。所以在使用NOSORT可選項的時候，數(shù)據(jù)庫管理員盡管放心大膽的使用。因為其實在不能夠使用這個選項的時候，數(shù)據(jù)庫也會明確的告知。為此其副作用就比較少，數(shù)據(jù)庫管理員只需要把這個可選項去掉然后重新執(zhí)行一次即可。不過這里需要注意的是，如果表中的記錄比較少的話，那么使用NOSORT選項的效果并不是很明顯。當采用insert into批量導入數(shù)據(jù)，并在這個過程中采用了Order by子句對索引關鍵字進行了排序的話，則此時采用NOSORT選項的話，往往能夠起到比較好的效果。

可選項二：NOLOGGING，是否需要記錄日志信息

在創(chuàng)建索引的時候，系統(tǒng)會把相關的信息存儲到日志信息中去。如果表中的記錄比較多，則需要一一的把這些信息記錄到日志文件中，這顯然會讓數(shù)據(jù)庫增加很大的工作量。從而增加索引創(chuàng)建的時間。為此在創(chuàng)建索引的過程中，如果有必要時，我們可以采用NOLOGGING選項，讓數(shù)據(jù)庫在創(chuàng)建索引的過程中，不產(chǎn)生任何重做日志信息。此時當表中的記錄比較多時，就可以明顯提高速度。

但是默認情況下，數(shù)據(jù)庫在在創(chuàng)建索引時，是不采用這個選項的，即會把相關的信息保存到重做日志中去。這雖然降低了索引創(chuàng)建的效率，但是如果遇到什么意外的話，卻可以利用重做日志來進行恢復。所以，此時數(shù)據(jù)庫管理員就比較難以抉擇了。一方面是數(shù)據(jù)的安全，另一方面是索引創(chuàng)建的速度。根據(jù)筆者的經(jīng)驗，只要數(shù)據(jù)庫服務器比較穩(wěn)定，而數(shù)據(jù)庫中約束機制又比較完善的話，那么在創(chuàng)建索引的過程中一般不會出現(xiàn)問題，可以放心大膽的使用這個可選項。

但是如果數(shù)據(jù)庫已經(jīng)使用了好幾年了。后來因為某種原因需要重建索引。在這種情況下，由于數(shù)據(jù)庫使用過程中很多因素數(shù)據(jù)庫管理員無法控制。此時為這種類型的數(shù)據(jù)庫創(chuàng)建索引時，為了保險起見還是不要采用這個選項好。因為此時遇到錯誤的幾率相對來說會搞一點。為此此時犧牲一下索引創(chuàng)建的速率，而提高數(shù)據(jù)的安全性還是有必要的。萬一遇到什么問題時，可以通過重做日志來及時的恢復數(shù)據(jù)，為企業(yè)用戶減少損失。

可選項三：COMPUTE STATISTICS，是否生成統(tǒng)計信息

如果管理員在創(chuàng)建索引時采用了這個選項，則數(shù)據(jù)庫將在創(chuàng)建索引的過程中以非常小的代價直接生成關于索引的相關統(tǒng)計信息，然后把這些信息存儲在數(shù)據(jù)字典中。這就可以避免以后對索引進行分析統(tǒng)計，而且優(yōu)化器在優(yōu)化SQL語句的時候可以隨機使用這些統(tǒng)計信息，以確定是否生成使用該索引的執(zhí)行計劃。通常情況下，在生成索引的過程中統(tǒng)計索引的相關信息，其所花的代價是最小的。無論從時間上，還是從硬件資源的耗費上，都是非常小的。所以，在創(chuàng)建索引的過程中統(tǒng)計相關的索引信息是非常有用的。

但是默認情況下，數(shù)據(jù)庫是不采用這個選項的。這主要是因為一些事物處理系統(tǒng)，索引的信息是經(jīng)常需要發(fā)生變化的。如果在索引創(chuàng)建的過程中統(tǒng)計了相關信息。這些信息隨著索引的調(diào)整等等原因會很快的過時。所以說，其在默認情況下沒有采用這個選項。可見這個選項并不是在任何情況下都能夠起到效果。但是如果這個數(shù)據(jù)庫系統(tǒng)是一個決策支持系統(tǒng)。其數(shù)據(jù)、索引等等在一段時間內(nèi)基本上是穩(wěn)定不變的。此時在創(chuàng)建索引時可以使用這個選項。如此的話，在生成索引時可以以最小的代價生成這些統(tǒng)計信息，方便優(yōu)化器使用。筆者在部署數(shù)據(jù)庫應用的時候，對于事務型的數(shù)據(jù)庫系統(tǒng)，一般不會啟用這個選項。但是對于一些決策性的數(shù)據(jù)庫系統(tǒng)或者數(shù)據(jù)倉庫中，創(chuàng)建索引時則筆者喜歡采用這個選項。這有助于提高數(shù)據(jù)庫的性能。因為優(yōu)化器在生成執(zhí)行計劃時，可以直接采用這個統(tǒng)計信息。所以，數(shù)據(jù)庫能夠在最短的時間內(nèi)確定需要采用的執(zhí)行計劃。而且在執(zhí)行計劃制定中參考了這個索引統(tǒng)計信息，為此所生成的執(zhí)行計劃在同等條件下可能更加的合理。

可選項四：ONLINE，DML操作與創(chuàng)建索引操作是否可以同時進行

默認情況下，數(shù)據(jù)庫系統(tǒng)是不允許DML操作與創(chuàng)建索引的操作同時進行的。也就是說，在創(chuàng)建索引的過程中，是不允許其他用戶對其所涉及的表進行任何的DML操作。這主要是因為對基礎表進行DML操作時，會對基礎表進行加鎖。所以在基礎表上的DDL事務沒有遞交之前，即沒有對基礎表進行解鎖之前，是無法對這基礎表創(chuàng)建索引的。反之亦然。顯然此時數(shù)據(jù)庫沒有采用這個ONLIE選項，繼之DML操作與創(chuàng)建索引操作同時進行，主要是從創(chuàng)建索引的效率出發(fā)的。防止因為兩個作業(yè)相互沖突，從而延長某個作業(yè)的運行時間。

但是有時會我們必須允許他們進行同時操作。如用戶可能一刻都不能夠離開數(shù)據(jù)庫系統(tǒng)，需要時時刻刻對數(shù)據(jù)庫基礎表進行DML操作。而此時由于某些原因，數(shù)據(jù)庫管理員又需要重新建立索引時，那么不得不在創(chuàng)建索引的語句中加入這個ONLINE選項。讓他們同時運行。此時雖然可能會延長索引創(chuàng)建作業(yè)的時間，但是可以保障用戶DML操作能夠正常進行。有時候犧牲這個代價是值得的。用戶是不能夠等的，而我們數(shù)據(jù)庫管理員則可以勉強的等一會兒。

當然，如果用戶對于這個DML操作及時性沒有這么高。如數(shù)據(jù)庫管理員在晚上員工沒有使用數(shù)據(jù)庫時創(chuàng)建索引時，則可以不帶這個選項。在限制用戶對基礎表進行DML操作的同時，提高數(shù)據(jù)庫創(chuàng)建索引的效率。

可選項五：PARALLEL，多服務進程創(chuàng)建索引

默認情況下，Oracle數(shù)據(jù)庫系統(tǒng)不采用這個選項。這并不是說這個選項不可用，而是因為大多數(shù)情況下企業(yè)部署Oracle數(shù)據(jù)庫時所采用的數(shù)據(jù)庫服務器往往只有單個CPU。此時數(shù)據(jù)庫系統(tǒng)是用一個服務進程來創(chuàng)建索引的。

如果企業(yè)的服務器有多個CPU的話，則可以在創(chuàng)建索引時采用這個選項。因為只要采用了這個選項，則數(shù)據(jù)庫就會使用多個服務進程來并行的創(chuàng)建索引，以提高索引創(chuàng)建的速度。為此，在同等條件下，多服務并行創(chuàng)建進索引并單服務創(chuàng)建索引速度要快的多。所以如果服務器中有多個CPU，而且需要創(chuàng)建的索引比較多或者基礎表中記錄比較多的話，則采用這個選項能夠大幅度的提高索引的創(chuàng)建效率。

故筆者建議，如果采用多CPU的服務器時，最好在創(chuàng)建索引時使用這個選項。不能夠浪費了服務器的CPU呀。不然的話，多CPU服務器的優(yōu)勢就體現(xiàn)不出來了。為此采用這個選項，也是物盡其用。希望本文講到的內(nèi)容對大家能有所幫助。