索引的分類 B Tree索引和Hash索引

索引是儲存引擎用來快速查詢記錄的一種資料結構，按照實現的方式有不同的種類，想b-tree索引，hash索引，空間資料索引和全文索引等。下面主要說一下b-tree索引和hash索引。

人們在談論索引的時候如果沒有特別說明，一般指的是b-tree索引。b-tree索引是使用b-tree資料結構來儲存索引的。b-tree通常意味著所有的值是按照順序儲存的。b-tree樹有如下幾個特徵：

⑴樹中每個結點至多有m 棵子樹；

⑵若根結點不是葉子結點，則至少有兩棵子樹；

⑶除根結點之外的所有非終端結點至少有[m/2] 棵子樹；

⑷所有的非終端結點中包含以下資訊資料：

（n，a0，k1，a1，k2，…，kn，an）

其中：ki（i=1,2,…,n）為關鍵碼，且kiai 為指向子樹根結點的指標(i=0,1,…,n)，且指標ai-1 所指子樹中所有結點的關鍵碼均小於ki (i=1,2,…,n)，an 所指子樹中所有結點的關鍵碼均大於kn.

n 為關鍵碼的個數。

⑸所有的葉子結點都出現在同一層次上，並且不帶資訊（可以看作是外部結點或查詢失敗的結點，實際上這些結點不存在，指向這些結點的指標為空）。即所有葉節點具有相同的深度，等於樹高度。

對於b-tree索引，儲存引擎在查詢記錄的時候不再是通過掃瞄全表來獲取需要的資料麼人是從索引的根節點進行搜尋，根節點的槽中存放了指向子節點的指標，儲存引擎根據這些指標向下查詢。最後找到葉子節點。葉子節點比較特殊，他的指標指向的是索引的資料。而且不同的儲存引擎實現也不一樣。在mysql中myisam中指標指向的是資料的指標，而在innodb中，直接存放的是資料。

那麼在什麼情況下b-tree可以使用索引呢？假設存在一張user表，我們對（「姓」，「名」，「出生日期」）建立符合索引，那麼在b-tree的key中就是按照姓，名，出生日期順序儲存的，這樣方便我們理解下面這些情況：

1，全值匹配，指的是索引中的所有列進行匹配。比如 where 姓=『張』 and 名=『小凡』and 出生年月=『1990-12-21』；

2，匹配最左字首。比如查詢姓=『張』，只能使用第一列。你想如果我們要名=『三』，那麼可以是『趙三』，『李三』索引中先根據姓排序，所以名=『三』的根本沒在一起，無法使用索引。

3，匹配列字首比如查詢『歐%』；

4，匹配範圍值可以使用索引列的第一列。

5，精確匹配某一列，在範圍匹配另外一列。

根據b-tree儲存的特點，很容易知道有一些情況是沒有辦法使用索引的。比如如下情況：

1，不是按照索引列最左側開始查詢。

2，跳過中介的列。

3，如果某個列採用範圍查詢，那麼右側的列都沒有辦法使用索引。

b-tree索引有一些獨特的好處的，比如在b-tree樹的key中存放了索引列的值，所以如果我們只需要查詢索引列的結果就可以直接使用索引而不需要去查詢記錄了。這就是覆蓋索引的優化。

另外，因為b-tree索引是有序的，所以除了查詢之外，索引還可以用於查詢中的order by 排序。

hash索引

雜湊索引是基於雜湊表實現的。只有精確匹配索引所有列的的查詢才有效。他的實現是儲存殷勤會對每一行資料的索引列計算雜湊碼，並將雜湊碼和指向該記錄的指標維護起來，對於hash相同的，採用鍊錶的方式解決衝突。類似於hashmap。因為索引的結構是十分緊湊的，所以hash索引的查詢很快。

但是hash索引也有他的限制：

1，hash索引只包含了雜湊值和行指標，索引不能避免讀取行，不能使用覆蓋索引。

2，hash索引並不是按照索引順序儲存的，無法用於排序。

3，hash索引不支援部分或者區域查詢，部分列的hash結果是不同的。

在mysql中innodb引擎有乙個特殊的功能叫做自適應雜湊索引，他會在記憶體中基於b-tree索引的基礎上面建立乙個雜湊索引，這讓b-tree索引頁具備了一些雜湊索引的優點。

在《高效能的mysql》這本樹中，作者舉了乙個自定義雜湊索引的列子。假設我們在乙個表中大量儲存了url，而且需要根據url來進行查詢。因為url比較長，這個時候如果我們使用b-tree索引來，索引會非常的大。解決的辦法是在列表中增加乙個列，用來存放url的雜湊值，可以通過crc32對url進行計算，並存放在列表中，在查詢的時候通過crc32對url進行計算匹配列表中的hash值。

但是這個地方需要注意hash衝突的問題，所以在查詢的時候需要新增url的匹配。

例如：where url_crc=crc32(「 and url=」

索引的分類 B Tree索引和Hash索引

索引的分類 B Tree索引和Hash索引

索引的分類 B Tree索引和Hash索引

Hash索引和BTree索引

相關推薦