索引是常見的數據庫對象，建立索引的目的是為了提高記錄的檢索速度。它的設置好壞，使用是否得當，極大地影響數據庫應用程序和Database的性能。雖然有許多資料講索引的用法，DBA和Developer們也經常與它打交道，但還是有不少的人對它存在誤解，比如我本人就不是很清楚這其中的道理。所以特此進行總結，也請大牛們來給檢查檢查，分享下你們的經驗。
一般來說，對於單列索引，只要Select、Delete、Update語句的Where條件中有此列，就會使用此索引。
對於多列索引，假如一個表中的主鍵（ID,Name,Age三個字段聯合索引），只有當Where條件中包含索引中的前一個或幾個列時才會用到索引。
如ID條件，ID、Age組合條件，ID、Name、Age組合條件，而僅有Name、Age條件，沒有ID條件是不會使用索引的。因為此索引是先根據ID排序，ID相同的再根據Name排序，ID、Name相同的再根據Age排序。
一般來說，滿足下列條件的應該建立索引：
1、列經常被用在Where條件中或連接條件中
2、列的數據比較分散，即重復值不多
3、列包含大量的空值
4、幾個列經常一起用在Where條件或連接條件中（聯合索引）
5、大部分的檢索只返回大表中的小部分記錄（2%~5%）
不應該建立索引的情況有：
1、表的數據量不大
2、列很少用在查詢條件中
3、大部分的檢索都返回大量的數據
4、表的Update操作很頻繁
但索引並非總是最佳選擇，如果發現Oracle在有索引的情況下，沒有使用索引，這並不是優化器出錯。在有些情況下，Oracle確實會選擇全表掃描（Full Table Scan),而非索引掃描（Index Scan)。這些情況通常有：
1、表未做統計，或者統計陳舊，導致Oracle判斷失誤。
2、根據該表擁有的記錄數和數據塊數，實際上全表掃描要比索引掃描更快。
但是，Oracle是否真正使用索引，使用索引是否真正有效，還是必須進行實地的測驗。合理的做法是，對縮寫的復雜sql,在將它寫入應用程序之前，先在產品數據庫上做一次執行計劃(explain)。explain會獲得Oracle對該sql的解析（plan）,可以明確地看到Oracle是如何優化該sql的。
如果經常做explain，就會發現，喜愛寫發扎的sql並不是好習慣，因為過分復雜的sql其解析計劃往往不盡如人意。事實上，如果庫表結構設計的合理，一般情況下我們很少需要寫復雜的sql。將復雜的Sql拆開，有時候會極大地提高效率，因為能獲得很好的優化。
通常情況下，通過索引查詢數據比全表掃描要快。同樣在聯結多個表時使用索引也可以提高效率。另一個使用索引的好處是，它提供了主鍵（primary key）的唯一性驗證。不過使用索引時也必須注意到它的代價。索引需要空間來存儲，也需要定期維護，每當有記錄在表中增減或索引列被修改時，索引本身也會被修改。這意味著每條記錄的Insert、Delete、Update將為此多付出4、5此的磁盤I/O。因為索引需要額外的存儲空間和處理，那些不必要的索引反而會使查詢反應時間變慢。
Oracle對索引有兩種訪問模式：
索引唯一掃描（Index Unique Scan）
索引范圍查詢（Index Range Scan)
適用於兩種情況：1、基於一個范圍的檢索 2、基於非唯一性索引的檢索
當where子句中有多個索引列，且包含非“=”號時，Oracle會放棄使用非“=”號的索引
當where子句中有多個索引列，且都為非“=”號時，Oracle將只使用一個索引，至於使用那個索引，這個還要看情況而定。
如果兩個或以上具有相同的等級，而我們只想使用其中的一個（通過它，檢索出的記錄數量少），我們可以使用下面的方法：
Ename ENo DNo EType
如果我們只想用到ENo上的索引（相對另外兩個條件記錄數量很少，做合並不劃算）則可改編為：
EName ENo DNo
同樣，如果我們想使用某個列上的索引，則不能對此列做運算。
SAL
不能使用SAL列上的索引，可改編為：
SAL
對Oracle的索引了解還不是很深入，只是浮於表面的認識，日後要多加使用研究。
