MySQL的B+Tree索引到底是咋回事？聚簇索引到底是如何長高的？

你肯定知道MySQL進行CRUD是在記憶體中進行的，也就是在Buffer Pool中。然後你也知道了當記憶體中沒有MySQL需要的資料時，MySQL會從Disk中透過IO操作將資料讀入記憶體中。讀取的單位呢就是：資料頁

一般資料頁長下面這樣

沒錯，資料頁中儲存著真實的資料，而且資料頁在記憶體中是以雙向聯表的方式組織起來的！如下圖

而在B+Tree的設定中，它要求主鍵索引時遞增的，也就是說如果主鍵索引時遞增的話，那麼就要求右側的資料頁中的所有資料均比左側資料頁中的資料大。但是很明顯上圖並不符合，因此需要透過頁分裂來調整成下面這樣。

好，現在你回想一下，之前你肯定有聽說過： MySQL的B+Tree聚簇索引，只有葉子節點才儲存真實的資料，而非葉子節點中儲存的是索引資料，而且葉子節點之間是透過雙向連結串列連線起來

沒錯，那所有的B+Tree的葉子節點就是上圖中的資料頁，並且它們確實是透過雙向連結串列關聯起來的！

我們接著往下看，如果只看上圖由資料頁連線起來的雙向連結串列的話，這時如果我們檢索id=7的資料行，那會發生什麼？

很明顯我們要從頭開始掃描！

那你可能會問：方才不是說B+Tree要求主鍵是遞增的嘛？並且有頁分裂機制保證右邊的資料頁中的所有資料均比它左邊的資料頁的索引值大。那進行二分查詢不行嘛？

答：是的，確實可以在單個資料頁中進行二分查詢，但是資料頁之間的組織關係是連結串列呀，所以從頭開始遍歷是避免不了的。

那MySQL怎麼辦的呢？

如下圖：MySQL針對諸多的資料頁抽象出了一個索引目錄

那有了這個索引目錄我們再在諸多的資料頁中檢索時看起來就容易多了！直接就擁有了二分檢索的能力！

而且這個所以目錄其實也是存在於資料頁中的，不同於葉子節點的是，它裡面只是儲存了索引資訊，而葉子節點中儲存的是真實資料？

而索引頁的誕生也就意味著B+Tree的雛形已經誕生了！

隨著使用者不斷的select，buffer pool中的資料頁的越來越多，那麼索引頁中的資料也會水漲船高。當現有的索引體量超過16KB（一個資料頁的容量）時就不得不搞一個新的索引頁來儲存新的索引資訊。這時這顆B+Tree就會慢慢變得越來越胖。

那你也知道B+Tree是B樹的變種，而B樹其實可以是2-3樹、2-3-4數....等等M階樹的泛稱，當每個節點中能儲存的元素達到上限後，樹就會長高 。

就像下圖這樣：