( 轉 ) 資料庫BTree索引、Hash索引、Bitmap位元影像索引的優缺點

標籤：bit   完全   特殊   hash演算法   排序   索引   就是   限制   合并   

測試於：MySQL 5.5.25

當前測試的版本是Mysql 5.5.25隻有BTree和Hash兩種索引類型，預設為BTree。Oracle或其他類型資料庫中會有Bitmap索引（位元影像索引），這裡作為比較也一起提供。

 

BTree索引

BTree（多路搜尋樹，並不是二叉的）是一種常見的資料結構。使用BTree結構可以顯著減少定位記錄時所經曆的中間過程，從而加快存取速度。按照翻譯，B 通常認為是Balance的簡稱。這個資料結構一般用於資料庫的索引，綜合效率較高。——百度百科

不適合：

• 單列索引的列不能包含null的記錄，複合索引的各個列不能包含同時為null的記錄，否則會全表掃描；
• 不適合索引值較少的列（重複資料較多的列）；
• 前置模糊查詢不能利用索引(like ‘%XX‘或者like ‘%XX%‘)

 

Hash散列索引

Hash散列索引是根據HASH演算法來構建的索引。雖然 Hash 索引效率高，但是 Hash 索引本身由於其特殊性也帶來了很多限制和弊端，主要有以下這些。

適合：

• 精確尋找非常快（包括= <> 和in），其檢索效率非常高，索引的檢索可以一次定位，不像BTree 索引需要從根節點到枝節點，所以 Hash 索引的查詢效率要遠高於 B-Tree 索引。

不適合：

• 不適合模糊查詢和範圍查詢（包括like，>，<，between……and等），由於 Hash 索引比較的是進行 Hash 運算之後的 Hash 值，所以它只能用於等值的過濾，不能用於基於範圍的過濾，因為經過相應的 Hash 演算法處理之後的 Hash 值的大小關係，並不能保證和Hash運算前完全一樣；
• 不適合排序，資料庫無法利用索引的資料來提升排序效能，同樣是因為Hash值的大小不確定；
• 複合索引不能利用部分索引欄位查詢，Hash 索引在計算 Hash 值的時候是複合式索引鍵合并後再一起計算 Hash 值，而不是單獨計算 Hash 值，所以通過複合式索引的前面一個或幾個索引鍵進行查詢的時候，Hash 索引也無法被利用。
• 同樣不適合索引值較少的列（重複值較多的列）；

 

Bitmap位元影像索引

 就是用位元影像表示的索引，對列的每個索引值建立一個位元影像。相對於BTree索引，佔用的空間非常小，建立和使用非常快。位元影像索引由於只儲存索引值的起止Rowid和位元影像,佔用的空間非常少。如test表中有state這樣一列，10行資料如下：

10    20    30    20    10    30    10    30    20    30

那麼會建立三個位元影像，如下：

BLOCK1    KEY=10  1    0    0    0    1    0    1    0    0    0   
BLOCK2    KEY=20  1    0    0    0    1    0    1    0    0    0 
BLOCK3    KEY=30  1    0    0    0    1    0    1    0    0    0

適合

• 適合決策支援系統；
• 當select count(XX) 時,可以直接存取索引中一個位元影像就快速得出統計資料；
• 當根據索引值做and，or或 in(x,y,..)查詢時，直接用索引的位元影像進行或運算,快速得出結果行資料。

不適合

• 不適合索引值較多的列（重複值較少的列）；
• 不適合update、insert、delete頻繁的列，代價很高。

 

原貼 : http://blog.sina.com.cn/s/blog_4b9eab320102w5vx.html

( 轉 ) 資料庫BTree索引、Hash索引、Bitmap位元影像索引的優缺點