數據庫為什么使用 B+ 樹？

前言

講到索引，第一反應肯定是能提高查詢效率。例如書的目錄，想要查找某一章節，會先從目錄中定位。如果沒有目錄，那么就需要將所有內容都看一遍才能找到。

索引的設計對程序的性能至關重要，若索引太少，對查詢性能受影響；而如果索引太多，則會影響增/改/刪等的性能。

知識點

MySQL 中一般支持以下幾種常見的索引：

B+樹索引

全文索引

哈希索引

我們今天重點來講下 B+樹索引，以及為什么要用 B+樹來作為索引的數據結構。

B+樹索引并不能直接找到具體的行，只是找到被查找行所在的頁，然后 DB 通過把整頁讀入內存，再在內存中查找。

1. 與二叉樹相比

二叉樹相比于順序查找的確減少了查找次數，但是在最壞情況下，二叉樹有可能退化為順序查找。而且就二叉樹本身來說，當數據庫的數據量特別大時，其層數也將特別大。二叉樹的高度一般是 log_2^n，B 樹的高度是 log_t^((n+1)/2) + 1，其高度約比 B 樹大 lgt 倍。n 是節點總數，t 是樹的最小度數。

2. 與 B樹相比

B 樹在提高 IO 性能的同時，并沒與解決元素遍歷時效率低下的問題，正是為了解決這個問題，B+數應運而生。B+數只需遍歷葉子節點即可實現整棵樹的遍歷，而 B 樹必須使用中序遍歷按序掃庫，B+樹支持范圍查詢非常方便。這才是數據庫選用 B+樹的主要原因。

另外，最后說一下，并不是說 B+樹就比 B 樹好，有很多基于頻率的搜索是選用 B樹，越頻繁 query 的結點越往根上走，前提是需要對 query 做統計，而且要對 key做一些變化。

無論是 B 樹還是 B+樹由于前邊幾層反復 query，因此早已被加載入內存，不會出現讀磁盤 IO。一般啟動的時候，就會主動換入內存。在內存中 B+樹并沒有優勢，只有在磁盤中 B+樹的威力才能顯現。

采用 B+ 樹的索引結構優點：

B+樹的高度一般為 2-4 層，所以查找記錄時最多只需要 2-4 次 IO，相對二叉平衡樹已經大

大降低了。

范圍查找時，能通過葉子節點的指針獲取數據。例如查找大于等于 3 的數據，當在葉子節點

中查到 3 時，通過 3 的尾指針便能獲取所有數據，而不需要再像二叉樹一樣再獲取到 3 的

父節點。

總結：

1)二叉查找樹(BST):解決了排序的基本問題,但是由于無法保證平衡,可能退化為鏈表

2)平衡二叉樹(AVⅥL):通過旋轉解決了平衡的問題,但是旋轉操作效率太低

3)紅黑樹:通過舍棄嚴格的平衡和引入紅黑節點,解決了 AⅥ旋轉效率過低的問題,但是在磁盤等場景下,樹仍然太高,IO 次數太多

4)B 樹:通過將二叉樹改為多路平衡查找樹,解決了樹過高的問題

5)B+樹:在 B 樹的基礎上,將非葉節點改造為不存儲數據的純索引節點,進一步降低了樹的高度;此外將葉節點使用指針連接成鏈表,范圍查詢更加高效。