ORACLE資料庫的索引類型及其適用情境____資料庫

邏輯上：
Single column 單行索引
Concatenated 多行索引
Unique 唯一索引
NonUnique 非唯一索引
Function-based函數索引
Domain 域索引
物理上：
Partitioned 分區索引
NonPartitioned 非分區索引
B-tree：
Normal 正常型B樹
Rever Key 反轉型B樹 
Bitmap 位元影像索引

1)b-tree索引 Oracle資料庫中最常見的索引類型是b-tree索引，也就是B-樹索引，以其同名的計算科學結構命名。每當你發布基本的沒有經過進 一步修改的CREATE INDEX語句時，就是在建立b-tree索引。這裡不打算對b-tree索引進行更多深入的探討，這些使用者都可以自己瞭解。基本上這些索引儲存你建立的 索引所在的列值以及用來尋找自身行的指向實際資料表的指標。記住，這也就意味著要進行多路查詢，其中一個查詢各個節點和索引的分葉節點，然後才是表的行自 身。這就是為什麼Oracle的最佳化器在某種情況下會選擇執行全表掃描而不執行索引尋找的原因了，因為全表掃描執行起來實際上可能會更快一些。還要注意的 是，如果你的索引是建立在多個列上的話，那麼第一列(leading column)非常重要。假設你有一個多列索引(也稱為級聯索引)，索引列的排列順序是c列到d列，你可以對使用該索引c列單獨進行一次查詢，但你不能使 用該索引對d列冶金行一次單獨的查詢。


2)基於函數的索引
如果在搜尋時你讀取很多行，或者你的索引選擇性不大，又或者你在級聯索引中使用了第一列以外的列，Oracle資料庫有時候會選擇不使用索 引。那麼如果你想要執行一個大小寫不敏感的搜尋呢?像下面的指令：WHERE UPPER(first_name) = ‘JOHN’。
 
　　這也不會使用first_name欄位上的索引。為什麼?因為Oracle不得不將UPPER函數用在該索引所有(ALL)的值上，所以還不如做一次全表掃描。所以，很多時候Oracle建立基於函數的索引就是為了這個目的。
3)反轉關鍵字索引
你還可以看到這些反轉關鍵字索引，而且不時還要用到這些索引。假設有一列包含了“餐廳甲”、“餐廳乙”、“餐廳丙”等類似名字。可能這不是 一個很好的例子，不過關鍵的一點是擁有很多唯一值，但其關鍵字的前面一部分變化不大。因為Oracle會在將REVERSE關鍵字指定給b-tree前把 REVERSE字串簡化，所以使用反轉關鍵字索引可能是最好的。這樣的一個索引可能更平衡、有用，搜尋起來更快。


Oracle還提供了很多更為複雜的索引類型。不過請注意，你最好全面閱讀過相關的說明文檔後再使用這些索引，因為它們各自都有各自特定的適用範圍。
1)位元影像索引(bitmap index)
假設資料庫表中有一列其選擇性非常窄，例如性別列，該用什麼類型的索引?你可能會考慮對其使用位元影像索引。因為位元影像索引正是為相異值很少的列 而建立的。但需要考慮的因素還不只這些。一般而言，只有當你對錶中值相宜度較小的多個不同的列都使用位元影像索引，這樣位元影像索引才有用，因為你可以一起使用這 些索引才能對列產生更大的選擇性，否則你還是需要對這些列進行一次全表掃描。例如，對於性別列，其索引只能有兩個唯一值，那麼用這個索引對錶的任何搜尋有 可能都返回一半的記錄。其次，這些索引是為資料倉儲而設計的，所以其假定條件是資料不會發生很大的改變。這些索引不能用來滿足交易資料庫或更新頻繁的資料 庫。應該說，對位元影像索引的表進行更新根本沒有一點效率。
2)位元影像串連索引(bitmap join index)
位元影像串連索引比位元影像索引更進了一步。這些索引將位元影像化的列完全從表資料中抽取出來，並將其儲存在索引中。其假定條件是這些列集合必須一起查 詢。同樣的，這也是為資料倉儲資料庫而設計的。除了在句法最後有一個WHERE子句之外，位元影像串連索引的建立指令就像建立位元影像索引的CREATE BITMAP INDEX一樣。
3)壓縮索引
壓縮索引實際是標準b-tree索引的一個選項。壓縮索引的分葉節點更少，所以總的I/O數量和需要的緩衝也更少。這些都意味著Oracle 的最佳化器更可能使用這些壓縮索引，而不傾向於使用標準的非壓縮索引。不過，這些好處也是有代價的，當你對這些壓縮索引進行存取操作時，要消耗更多的CPU 來進行解壓縮。而且，當你閱讀關於最佳化器如何使用這些索引，又是如何選擇合適的壓縮層級的資料時，就開始變得晦澀了。不同的使用者不同的設定從壓縮索引中得 到的好處也可能會有所不同。
4)降序索引(descending index)
這是基於函數索引的一種特殊類型。降序索引可以顯著最佳化ORDER BY x, y, z DESC子句查詢的。
5)分區索引(partitioned index)
如果你的資料庫中有一個分區表，你就有機會體驗幾種新的索引類型，從貫穿所有分區的全域分區索引(global)和集中於各個單獨分區的本地分區索引(local)。這裡不再進行贅述，想知道細節問題可以查詢相關文獻。
6)索引組織表(index organized table，IOT)
這是在Oracle 9i中引進的一種新類型表。Oracle會將級聯索引及其擴充類型的索引用於表中所有的列。當所有資料都載入到索引結構之後，表就成多餘的了，你盡可以將表本身刪除掉。這就是索引組織表。
7)簇索引(cluster index)
基本上，簇索引就是將多個表的相同列放在一起，而對該列使用用一個簇索引。這種索引在實際應用中比較少，因為還有各種有待解決的效能問題存在。
8)域索引(domain index)
當我們建立為使用者自訂資料類型(datatype)建立使用者自訂索引類型(indextype)時就要使用域索引。
9)隱藏索引(invisible index)
這是Oracle 11g中推出的新特性。其建立過程和標準索引一樣，但建立後對於基於代價的最佳化器(CBO)是不可見的。這可以讓你對效能進行大型測試查詢，而不會影響現有的正在啟動並執行應用程式。
10)虛擬索引(virtual index)
這是為測試人員和開發人員準備的又一個工具。虛擬索引(不分配段空間)可以讓你在不需要實際建立索引的情況下，測試新索引及其對查詢計劃的影響。對於GB級的表來說，構建索引非常耗費資源而且還要佔用大量時間。
11)其他的索引類型
Oracle資料庫還提供了很多其他類型的索引，例如用來為字元型大型二進位對象(CLOB)或其他大型文本資料構建索引的Oracle TEXT，Oracle Spatial等。有興趣的讀者可以自己尋找相關資料瞭解。
都是為了最佳化器
如果你曾經廣泛接觸過MySQL和其他的資料庫，你會發現甲骨文雖然是全球領先的資料庫供應商，但它們的資料庫對於使用者來說用起來其實並不 是很方便。提到最佳化器這個問題可能有點離題了，不過Oracle資料庫最基本的食料就是最佳化器了，這的確是種挺特別的調料，而且變得越來越美味了。市面上 有很多以Oracle基於代價的最佳化器(Cost Based Optimizer，CBO)為主題內容的書籍，專門介紹分析表和索引的技巧和策略。
對於資料庫，除了需要一直更新你的統計資訊之外，你可能還需要不斷測試新的查詢。使用解析計劃機制，並進行最佳化以便減少總I/O量以及排序和合并資料的計算量，只有這樣你才能獲得更好的效能表現。
總結
雖然Oracle資料庫的索引世界有點嚇人，不過實際上你平常經常使用的索引就只有那麼一些。而且，不管唱反調的人怎樣詆毀，Oracle 的最佳化器都已經設計相當出色;總體而言，Oracle很擅長於讓你的資料庫運行地更有效率。雖然這並不意味著你不需要對自己的SQL進行調優，不過，如果 你一直保持著最新的統計資訊，並讓Oracle為你整理出你所需要的最小資料集的話，它能夠以極快的速度滿足你的需要。