【深刻學習MySQL】MySQL的索引結構爲何使用B+樹？

時間 2019-11-09

標籤深刻學習MySQL mysql 索引結構爲何使用欄目 MySQL 简体版

原文原文鏈接

前言

在MySQL中，不管是Innodb仍是MyIsam，都使用了B+樹做索引結構(這裏不考慮hash等其餘索引)。本文將從最普通的二叉查找樹開始，逐步說明各類樹解決的問題以及面臨的新問題，從而說明MySQL爲何選擇B+樹做爲索引結構。html

1、二叉查找樹(BST)：不平衡

二叉查找樹(BST，Binary Search Tree)，也叫二叉排序樹，在二叉樹的基礎上須要知足：任意節點的左子樹上全部節點值不大於根節點的值，任意節點的右子樹上全部節點值不小於根節點的值。以下是一顆BST(圖片來源)。設計

當須要快速查找時，將數據存儲在BST是一種常見的選擇，由於此時查詢時間取決於樹高，平均時間複雜度是O(lgn)。然而，BST可能長歪而變得不平衡，以下圖所示(圖片來源)，此時BST退化爲鏈表，時間複雜度退化爲O(n)。指針

爲了解決這個問題，引入了平衡二叉樹。

2、平衡二叉樹(AVL)：旋轉耗時

AVL樹是嚴格的平衡二叉樹，全部節點的左右子樹高度差不能超過1；AVL樹查找、插入和刪除在平均和最壞狀況下都是O(lgn)。

AVL實現平衡的關鍵在於旋轉操做：插入和刪除可能破壞二叉樹的平衡，此時須要經過一次或屢次樹旋轉來從新平衡這個樹。當插入數據時，最多隻須要1次旋轉(單旋轉或雙旋轉)；可是當刪除數據時，會致使樹失衡，AVL須要維護從被刪除節點到根節點這條路徑上全部節點的平衡，旋轉的量級爲O(lgn)。

因爲旋轉的耗時，AVL樹在刪除數據時效率很低；在刪除操做較多時，維護平衡所需的代價可能高於其帶來的好處，所以AVL實際使用並不普遍。

3、紅黑樹：樹過高

與AVL樹相比，紅黑樹並不追求嚴格的平衡，而是大體的平衡：只是確保從根到葉子的最長的可能路徑很少於最短的可能路徑的兩倍長。從實現來看，紅黑樹最大的特色是每一個節點都屬於兩種顏色(紅色或黑色)之一，且節點顏色的劃分須要知足特定的規則(具體規則略)。紅黑樹示例以下（圖片來源）：

與AVL樹相比，紅黑樹的查詢效率會有所降低，這是由於樹的平衡性變差，高度更高。但紅黑樹的刪除效率大大提升了，由於紅黑樹同時引入了顏色，當插入或刪除數據時，只須要進行O(1)次數的旋轉以及變色就能保證基本的平衡，不須要像AVL樹進行O(lgn)次數的旋轉。總的來講，紅黑樹的統計性能高於AVL。

所以，在實際應用中，AVL樹的使用相對較少，而紅黑樹的使用很是普遍。例如，Java中的TreeMap使用紅黑樹存儲排序鍵值對；Java8中的HashMap使用鏈表+紅黑樹解決哈希衝突問題(當衝突節點較少時，使用鏈表，當衝突節點較多時，使用紅黑樹)。

對於數據在內存中的狀況（如上述的TreeMap和HashMap），紅黑樹的表現是很是優異的。可是對於數據在磁盤等輔助存儲設備中的狀況（如MySQL等數據庫），紅黑樹並不擅長，由於紅黑樹長得仍是過高了。當數據在磁盤中時，磁盤IO會成爲最大的性能瓶頸，設計的目標應該是儘可能減小IO次數；而樹的高度越高，增刪改查所須要的IO次數也越多，會嚴重影響性能。

4、B樹：爲磁盤而生

B樹也稱B-樹(其中-不是減號)，是爲磁盤等輔存設備設計的多路平衡查找樹，與二叉樹相比，B樹的每一個非葉節點能夠有多個子樹。所以，當總節點數量相同時，B樹的高度遠遠小於AVL樹和紅黑樹(B樹是一顆「矮胖子」)，磁盤IO次數大大減小。

定義B樹最重要的概念是階數(Order)，對於一顆m階B樹，須要知足如下條件：

每一個節點最多包含 m 個子節點。
若是根節點包含子節點，則至少包含 2 個子節點；除根節點外，每一個非葉節點至少包含 m/2 個子節點。
擁有 k 個子節點的非葉節點將包含 k - 1 條記錄。
全部葉節點都在同一層中。

能夠看出，B樹的定義，主要是對非葉結點的子節點數量和記錄數量的限制。

下圖是一個3階B樹的例子（圖片來源）：

B樹的優點除了樹高小，還有對訪問局部性原理的利用。所謂局部性原理，是指當一個數據被使用時，其附近的數據有較大機率在短期內被使用。B樹將鍵相近的數據存儲在同一個節點，當訪問其中某個數據時，數據庫會將該整個節點讀到緩存中；當它臨近的數據緊接着被訪問時，能夠直接在緩存中讀取，無需進行磁盤IO；換句話說，B樹的緩存命中率更高。

B樹在數據庫中有一些應用，如mongodb的索引使用了B樹結構。可是在不少數據庫應用中，使用了是B樹的變種B+樹。

5、B+樹

B+樹也是多路平衡查找樹，其與B樹的區別主要在於：

B樹中每一個節點（包括葉節點和非葉節點）都存儲真實的數據，B+樹中只有葉子節點存儲真實的數據，非葉節點只存儲鍵。在MySQL中，這裏所說的真實數據，多是行的所有數據（如Innodb的聚簇索引），也可能只是行的主鍵（如Innodb的輔助索引），或者是行所在的地址（如MyIsam的非聚簇索引）。
B樹中一條記錄只會出現一次，不會重複出現，而B+樹的鍵則可能重複重現——必定會在葉節點出現，也可能在非葉節點重複出現。
B+樹的葉節點之間經過雙向鏈表連接。
B樹中的非葉節點，記錄數比子節點個數少1；而B+樹中記錄數與子節點個數相同。

由此，B+樹與B樹相比，有如下優點：

更少的IO次數：B+樹的非葉節點只包含鍵，而不包含真實數據，所以每一個節點存儲的記錄個數比B數多不少（即階m更大），所以B+樹的高度更低，訪問時所須要的IO次數更少。此外，因爲每一個節點存儲的記錄數更多，因此對訪問局部性原理的利用更好，緩存命中率更高。
更適於範圍查詢：在B樹中進行範圍查詢時，首先找到要查找的下限，而後對B樹進行中序遍歷，直到找到查找的上限；而B+樹的範圍查詢，只須要對鏈表進行遍歷便可。
更穩定的查詢效率：B樹的查詢時間複雜度在1到樹高之間(分別對應記錄在根節點和葉節點)，而B+樹的查詢複雜度則穩定爲樹高，由於全部數據都在葉節點。

B+樹也存在劣勢：因爲鍵會重複出現，所以會佔用更多的空間。可是與帶來的性能優點相比，空間劣勢每每能夠接受，所以B+樹的在數據庫中的使用比B樹更加普遍。

6、感覺B+樹的威力

前面說到，B樹/B+樹與紅黑樹等二叉樹相比，最大的優點在於樹高更小。實際上，對於Innodb的B+索引來講，樹的高度通常在2-4層。下面來進行一些具體的估算。

樹的高度是由階數決定的，階數越大樹越矮；而階數的大小又取決於每一個節點能夠存儲多少條記錄。Innodb中每一個節點使用一個頁(page)，頁的大小爲16KB，其中元數據只佔大約128字節左右(包括文件管理頭信息、頁面頭信息等等)，大多數空間都用來存儲數據。

對於非葉節點，記錄只包含索引的鍵和指向下一層節點的指針。假設每一個非葉節點頁面存儲1000條記錄，則每條記錄大約佔用16字節；當索引是整型或較短的字符串時，這個假設是合理的。延伸一下，咱們常常聽到建議說索引列長度不該過大，緣由就在這裏：索引列太長，每一個節點包含的記錄數太少，會致使樹過高，索引的效果會大打折扣，並且索引還會浪費更多的空間。
對於葉節點，記錄包含了索引的鍵和值(值多是行的主鍵、一行完整數據等，具體見前文)，數據量更大。這裏假設每一個葉節點頁面存儲100條記錄(實際上，當索引爲聚簇索引時，這個數字可能不足100；當索引爲輔助索引時，這個數字可能遠大於100；能夠根據實際狀況進行估算)。

對於一顆3層B+樹，第一層(根節點)有1個頁面，能夠存儲1000條記錄；第二層有1000個頁面，能夠存儲1000*1000條記錄；第三層(葉節點)有1000*1000個頁面，每一個頁面能夠存儲100條記錄，所以能夠存儲1000*1000*100條記錄，即1億條。而對於二叉樹，存儲1億條記錄則須要26層左右。