oracle索引總結

轉載:http://www.cnblogs.com/noures/archive/2012/09/28/2707031.html

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爲你整理出你所需要的最小數據集的話,它能夠以極快的速度滿足你的需要。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章