有些新手在Oracle數據庫中創建索引時往往不會使用可選項。其實，有時候在合適的場合使用一些可選項，可以提高索引的創建速度。如為了大批量導入數據，我們往往會先取消索引其以提高插入的速度。然後等數據導入完畢後再重新創建索引。在這個過程中如果能夠采用一些可選項，則可以縮短索引創建的時間。在Oracle數據庫中提供了豐富的可選項。我們常用的可選項主要有以下這些。
可選項一：NOSORT，記錄排序可選項
默認情況下，在表中創建索引的時候，會對表中的記錄進行排序，排序成功後再創建索引。但是當記錄比較多的是，這個排序作業會占用比較多的時間，這也就增加了索引建立的時間（排序作業是在索引創建作業中完成）。有時候，我們導入數據的時候，如采用insert into 語句插入數據過程中同時采用Order by子句對索引字段進行了排序。此時如果在索引創建過程中再進行排序的話，就有點脫褲子放屁，多此一舉了。為此在重新創建索引時，如果表中的數據已經排好序了（按索引字段排序），那麼在創建索引時就不需要為此重新排序。此時在創建索引時，數據庫管理員就可以使用NOSORT可選項，告訴數據庫系統不需要對表中當記錄進行重新排序了。
采用了這個選項之後，如果表中的記錄已經按順序排列，那麼在重新創建索引的時候，就不會重新排序，可以提高索引創建的時間，節省內存中的排序緩存空間。相反，如果表中的記錄是不按索引關鍵字排序的話，那麼此時采用NOSORT關鍵字的話，系統就會提示錯誤信息，並拒絕創建索引。所以在使用NOSORT可選項的時候，數據庫管理員盡管放心大膽的使用。因為其實在不能夠使用這個選項的時候，數據庫也會明確的告知。為此其副作用就比較少，數據庫管理員只需要把這個可選項去掉然後重新執行一次即可。不過這裡需要注意的是，如果表中的記錄比較少的話，那麼使用NOSORT選項的效果並不是很明顯。當采用insert into批量導入數據，並在這個過程中采用了Order by子句對索引關鍵字進行了排序的話，則此時采用NOSORT選項的話，往往能夠起到比較好的效果。
可選項二：NOLOGGING，是否需要記錄日志信息
在創建索引的時候，系統會把相關的信息存儲到日志信息中去。如果表中的記錄比較多，則需要一一的把這些信息記錄到日志文件中，這顯然會讓數據庫增加很大的工作量。從而增加索引創建的時間。為此在創建索引的過程中，如果有必要時，我們可以采用NOLOGGING選項，讓數據庫在創建索引的過程中，不產生任何重做日志信息。此時當表中的記錄比較多時，就可以明顯提高速度。
但是默認情況下，數據庫在在創建索引時，是不采用這個選項的，即會把相關的信息保存到重做日志中去。這雖然降低了索引創建的效率，但是如果遇到什麼意外的話，卻可以利用重做日志來進行恢復。所以，此時數據庫管理員就比較難以抉擇了。一方面是數據的安全，另一方面是索引創建的速度。根據筆者的經驗，只要數據庫服務器比較穩定，而數據庫中約束機制又比較完善的話，那麼在創建索引的過程中一般不會出現問題，可以放心大膽的使用這個可選項。
但是如果數據庫已經使用了好幾年了。後來因為某種原因需要重建索引。在這種情況下，由於數據庫使用過程中很多因素數據庫管理員無法控制。此時為這種類型的數據庫創建索引時，為了保險起見還是不要采用這個選項好。因為此時遇到錯誤的幾率相對來說會搞一點。為此此時犧牲一下索引創建的速率，而提高數據的安全性還是有必要的。萬一遇到什麼問題時，可以通過重做日志來及時的恢復數據，為企業用戶減少損失。
可選項三：COMPUTE STATISTICS，是否生成統計信息
如果管理員在創建索引時采用了這個選項，則數據庫將在創建索引的過程中以非常小的代價直接生成關於索引的相關統計信息，然後把這些信息存儲在數據字典中。這就可以避免以後對索引進行分析統計，而且優化器在優化SQL語句的時候可以隨機使用這些統計信息，以確定是否生成使用該索引的執行計劃。通常情況下，在生成索引的過程中統計索引的相關信息，其所花的代價是最小的。無論從時間上，還是從硬件資源的耗費上，都是非常小的。所以，在創建索引的過程中統計相關的索引信息是非常有用的。
但是默認情況下，數據庫是不采用這個選項的。這主要是因為一些事物處理系統，索引的信息是經常需要發生變化的。如果在索引創建的過程中統計了相關信息。這些信息隨著索引的調整等等原因會很快的過時。所以說，其在默認情況下沒有采用這個選項。可見這個選項並不是在任何情況下都能夠起到效果。但是如果這個數據庫系統是一個決策支持系統。其數據、索引等等在一段時間內基本上是穩定不變的。此時在創建索引時可以使用這個選項。如此的話，在生成索引時可以以最小的代價生成這些統計信息，方便優化器使用。筆者在部署數據庫應用的時候，對於事務型的數據庫系統，一般不會啟用這個選項。但是對於一些決策性的數據庫系統或者數據倉庫中，創建索引時則筆者喜歡采用這個選項。這有助於提高數據庫的性能。因為優化器在生成執行計劃時，可以直接采用這個統計信息。所以，數據庫能夠在最短的時間內確定需要采用的執行計劃。而且在執行計劃制定中參考了這個索引統計信息，為此所生成的執行計劃在同等條件下可能更加的合理。
可選項四：ONLINE，DML操作與創建索引操作是否可以同時進行
默認情況下，數據庫系統是不允許DML操作與創建索引的操作同時進行的。也就是說，在創建索引的過程中，是不允許其他用戶對其所涉及的表進行任何的DML操作。這主要是因為對基礎表進行DML操作時，會對基礎表進行加鎖。所以在基礎表上的DDL事務沒有遞交之前，即沒有對基礎表進行解鎖之前，是無法對這基礎表創建索引的。反之亦然。顯然此時數據庫沒有采用這個ONLIE選項，繼之DML操作與創建索引操作同時進行，主要是從創建索引的效率出發的。防止因為兩個作業相互沖突，從而延長某個作業的運行時間。
但是有時會我們必須允許他們進行同時操作。如用戶可能一刻都不能夠離開數據庫系統，需要時時刻刻對數據庫基礎表進行DML操作。而此時由於某些原因，數據庫管理員又需要重新建立索引時，那麼不得不在創建索引的語句中加入這個ONLINE選項。讓他們同時運行。此時雖然可能會延長索引創建作業的時間，但是可以保障用戶DML操作能夠正常進行。有時候犧牲這個代價是值得的。用戶是不能夠等的，而我們數據庫管理員則可以勉強的等一會兒。
當然，如果用戶對於這個DML操作及時性沒有這麼高。如數據庫管理員在晚上員工沒有使用數據庫時創建索引時，則可以不帶這個選項。在限制用戶對基礎表進行DML操作的同時，提高數據庫創建索引的效率。
可選項五：PARALLEL，多服務進程創建索引
默認情況下，Oracle數據庫系統不采用這個選項。這並不是說這個選項不可用，而是因為大多數情況下企業部署Oracle數據庫時所采用的數據庫服務器往往只有單個CPU。此時數據庫系統是用一個服務進程來創建索引的。
如果企業的服務器有多個CPU的話，則可以在創建索引時采用這個選項。因為只要采用了這個選項，則數據庫就會使用多個服務進程來並行的創建索引，以提高索引創建的速度。為此，在同等條件下，多服務並行創建進索引並單服務創建索引速度要快的多。所以如果服務器中有多個CPU，而且需要創建的索引比較多或者基礎表中記錄比較多的話，則采用這個選項能夠大幅度的提高索引的創建效率。
故筆者建議，如果采用多CPU的服務器時，最好在創建索引時使用這個選項。不能夠浪費了服務器的CPU呀。不然的話，多CPU服務器的優勢就體現不出來了。為此采用這個選項，也是物盡其用。希望本文講到的內容對大家能有所幫助。
