選項1: NOSORT，記錄排序選項。
默認情況下，在表中創建索引時，會對表中的記錄進行排序，排序成功後會創建索引。但是，當記錄較多時，這種排序作業會占用更多的時間，從而增加索引創建的時間(排序作業在索引創建作業中完成)。有時，當我們導入數據時，例如，當我們用insert into語句插入數據時，我們還使用Order by子句對索引字段進行排序。此時，如果在索引創建過程中再進行排序，那就有點脫褲子放屁了。因此，在重新創建索引時，如果表中的數據已經有序(按索引字段排序)，那麽在創建索引時就沒有必要重新排序。此時，在創建索引時，數據庫管理員可以使用NOSORT選項告訴數據庫系統，不需要對表中的記錄重新排序。
采用該選項後，如果表中的記錄按順序排列，則在重新創建索引時不會重新排序，可以提高索引創建的時間，節省內存中的排序緩存空間。相反，如果表中的記錄沒有按索引關鍵字排序，那麽此時如果使用NOSORT關鍵字，系統會提示錯誤信息，拒絕創建索引。因此，在使用NOSORT選項時，數據庫管理員可以大膽使用。因為其實當妳不能使用這個選項的時候，數據庫會明確通知妳。因此，副作用較少，數據庫管理員只需刪除該選項並再次執行即可。但這裏需要註意的是，如果表中記錄較少，使用NOSORT選項的效果並不明顯。當數據是通過insert into批量導入的，並且在這個過程中索引關鍵字是按Order by子句排序的，那麽NOSORT選項往往能起到更好的作用。
選項二:NOLOGGING，需要記錄日誌信息嗎？
創建索引時，系統會將相關信息存儲在日誌信息中。如果表中有很多記錄，就需要將這些信息逐個記錄到日誌文件中，這顯然會增加數據庫的工作量。從而增加了索引創建的時間。因此，在創建索引的過程中，如果有必要，我們可以使用NOLOGGING選項，使數據庫在創建索引的過程中不生成任何重做日誌信息。此時，當表中記錄較多時，速度可以明顯提高。
但是默認情況下，數據庫在創建索引時不使用這個選項，也就是說，它會將相關信息保存到重做日誌中。雖然這降低了索引創建的效率，但在出現任何意外的情況下，重做日誌都可以用於恢復。所以，這個時候，數據庫管理員就比較難選了。壹方面是數據的安全性，另壹方面是索引創建的速度。根據筆者的經驗，只要數據庫服務器比較穩定，數據庫中的約束機制比較完善，在創建索引的過程中壹般不會出現問題，可以大膽使用這個選項。
但是如果數據庫已經用了好幾年。後來，由於某種原因，需要重建索引。在這種情況下，由於數據庫使用過程中的諸多因素，數據庫管理員無法控制。此時，在為這種類型的數據庫創建索引時，為了安全起見，最好不要使用該選項。因為這個時候遇到錯誤的概率比較小。為此，需要犧牲索引創建的速度，提高數據的安全性。壹旦出現問題，可以通過重做日誌來及時恢復數據，從而減少企業用戶的損失。
選項3:計算統計，是否生成統計。
如果管理員在創建索引時采用了這個選項，那麽在創建索引的過程中，數據庫會以非常小的代價直接生成關於該索引的相關統計信息，然後將這些信息存儲在數據字典中。這可以避免將來對索引進行分析和計數，優化器可以在優化SQL語句時隨機使用這些統計信息來確定是否使用索引生成執行計劃。壹般來說，在生成指數的過程中，統計指數的相關信息花費最少。從時間和硬件資源的消耗來看，它是非常小的。因此，在創建索引的過程中，統計相關的索引信息是非常有用的。
但是默認情況下，數據庫不使用該選項。這主要是因為壹些事物處理系統經常需要改變索引的信息。如果在創建索引的過程中計算相關信息。這些信息會隨著指數的調整等原因而迅速過時。因此，默認情況下，它不使用此選項。可以看出，這個選項並不是在所有情況下都有效。但是如果這個數據庫系統是壹個決策支持系統。它的數據、指數等在壹段時間內基本穩定。此時創建索引時，可以使用此選項。這樣，在生成索引時可以用最小的代價生成這些統計信息，方便優化器使用。部署數據庫應用程序時，對於事務性數據庫系統，通常不啟用此選項。但是對於壹些決策數據庫系統或者數據倉庫，我喜歡在創建索引的時候使用這個選項。這有助於提高數據庫的性能。因為優化器可以在生成執行計劃時直接使用這些統計信息。因此，數據庫可以在最短的時間內確定需要采用的執行計劃。而且在制定執行計劃時參考了這個指標的統計信息，在同等條件下，為此生成的執行計劃可能更合理。
選項4:可以同時執行聯機、DML和索引創建嗎？
默認情況下，數據庫系統不允許DML操作與索引創建操作同時執行。也就是說，在創建索引的過程中，不允許其他用戶對涉及的表執行任何DML操作。這主要是因為當對基本表執行DML操作時，它將被鎖定。因此，在提交基表上的DDL事務之前，即在解鎖基表之前，不可能在基表上創建索引。或者反過來，達拉斯到禮堂很明顯，這個時候數據庫沒有采用這個ONLIE選項，然後同時進行DML操作和索引創建操作，主要是從索引創建的效率來看。防止由於兩個作業相互沖突而延長作業的運行時間。
但有時我們不得不允許它們同時運作。如果用戶可能壹刻也離不開數據庫系統，那麽就需要壹直對數據庫的基本表進行DML操作。此時，由於某種原因，當數據庫管理員需要重新建立索引時，他必須將這個ONLINE選項添加到創建索引的語句中。此時讓它們同時運行，雖然可能會延長索引創建作業的時間，但可以保證用戶DML的正常運行。有時候犧牲是值得的。用戶不能等，但我們數據庫管理員可以等壹會兒。
當然如果用戶對這個DML操作不是那麽及時的話。如果數據庫管理員在員工不使用數據庫的晚上創建索引，則可以省略該選項。在限制用戶對基本表進行DML操作的同時，提高了數據庫索引的效率。
選項5:並行的多服務流程創建索引。
默認情況下，Oracle數據庫系統不使用此選項。這並不是說這個選項不可用，而是因為在大多數情況下，企業用來部署Oracle數據庫的數據庫服務器往往只有壹個CPU。此時，數據庫系統使用服務進程來創建索引。
如果企業的服務器有多個CPU，您可以在創建索引時使用該選項。因為只要采用這個選項，數據庫就會使用多個服務進程並行創建索引，提高索引創建的速度。因此，在相同條件下，多個服務並行創建索引比單個服務創建索引要快得多。因此，如果服務器中有多個CPU，並且要創建的索引或基本表中的記錄很多，那麽這個選項可以大大提高索引創建的效率。
因此，作者建議，如果使用多CPU服務器，在創建索引時最好使用該選項。不能浪費服務器的CPU。否則多CPU服務器的優勢就體現不出來。為此，采用這個選項也是物盡其用。希望本文提到的內容能對大家有所幫助。