在關系型數據庫管理系統如MySQL中，索引是提升數據查詢效率的關鍵組件。而B+樹（B-Tree的變種）被廣泛用作索引的數據結構，這背后有著深刻的計算機科學原理和實際應用考量。本文將從數據處理與存儲服務的角度，解析MySQL選擇B+樹的核心原因。

一、 索引的核心需求與B+樹的特性匹配

數據庫索引本質上是一種幫助數據庫系統高效檢索數據的數據結構。它需要滿足幾個核心需求：

1. 高效的查找效率：支持快速的等值查詢和范圍查詢。
2. 適應磁盤I/O特性：磁盤讀寫速度遠慢于內存，因此數據結構應盡量減少磁盤I/O次數（即樹的高度要低）。
3. 支持高效的插入和刪除：在數據動態增刪時，能保持結構的平衡，避免性能急劇退化。
4. 有序性：便于進行排序和范圍掃描。

B+樹完美地契合了這些需求：

• 多路平衡查找樹：B+樹是一個多叉樹，每個節點可以包含多個鍵值和指針。這使其擁有更“矮胖”的形態，極大地降低了樹的高度。對于一個存儲海量數據的索引，樹的高度可能僅為3-4層，這意味著查詢任何記錄最多只需要3-4次磁盤I/O，效率極高。
• 所有數據存儲在葉子節點：B+樹的所有真實數據記錄（或指向記錄的指針）都存儲在最后一層的葉子節點上，并且葉子節點之間通過指針串聯成一個有序鏈表。這一設計帶來了兩大核心優勢：

1. 更穩定的查詢效率：任何關鍵字的查找路徑長度都相同，都等于樹高，查詢性能穩定可預測。

1. 卓越的范圍查詢性能：當進行范圍查詢（如WHERE id BETWEEN 100 AND 200）時，只需在葉子節點層找到起始位置，然后順著鏈表遍歷即可，無需回溯到上層節點，效率極高。

• 內部節點僅存儲鍵值和指針：內部節點（非葉子節點）不存儲實際數據行，只存儲鍵值和指向子節點的指針。這使得單個內部節點可以容納更多的“分支”，進一步降低了樹的高度，減少了磁盤I/O。

二、 與B樹、哈希表等結構的對比

為了更好地理解B+樹的優勢，可以將其與其他常見數據結構對比：

• 對比B樹：B樹（B-Tree）的節點既存儲鍵值也存儲對應的數據指針。這意味著數據可能分布在樹的任何一層。這在進行范圍查詢時效率不如B+樹，因為B樹需要進行中序遍歷，可能涉及多次不同層的磁盤訪問。而B+樹的范圍查詢集中在連續的葉子節點上，順序讀盤效率高得多。由于B+樹內部節點更“精簡”，在相同磁盤頁大小下能容納更多的分支因子，樹高更低。
• 對比哈希表：哈希表支持O(1)時間復雜度的等值查詢，速度極快。但它存在致命缺陷：不支持高效的范圍查詢和排序，因為哈希函數打亂了數據原有的順序。哈希索引在數據量增大、發生哈希沖突時，性能可能不穩定。因此，哈希索引在MySQL中通常僅用于某些特定的存儲引擎（如MEMORY）或配合B+樹索引（如自適應哈希索引）作為補充，無法作為主流索引結構。
• 對比二叉搜索樹（如AVL、紅黑樹）：這類樹在內存中效率很高，但每個節點最多只有兩個分支。當數據量龐大時，樹會變得非常高。將這樣的高樹存儲在磁盤上，意味著一次查詢可能需要幾十甚至上百次磁盤I/O，這是完全無法接受的。B+樹通過“多路”特性解決了這個問題。

三、 契合數據處理與存儲服務的硬件特性

數據庫運行在由內存和磁盤（或SSD）組成的存儲體系上。磁盤以“頁”（通常為4KB、16KB等）為單位進行讀寫，每次I/O操作讀取一整頁數據是最高效的。
B+樹的設計充分考慮了這一點：

• 節點大小與磁盤頁對齊：數據庫系統會將B+樹的一個節點大小設置為等于或數倍于磁盤頁大小（例如InnoDB默認頁大小為16KB）。這樣，每次磁盤I/O就能完整地讀入一個節點（包含多個鍵值和指針），極大提升了I/O效率。
• 順序訪問優勢：如前所述，B+樹葉子節點的鏈表結構，使得順序掃描（全表掃描、范圍掃描）的性能極佳，這非常符合磁盤順序讀遠快于隨機讀的特性。

四、

MySQL（尤其是其默認存儲引擎InnoDB）選擇B+樹作為索引的底層數據結構，是理論特性與工程實踐結合的典范。它通過多路平衡、數據僅存于葉子節點、葉子節點鏈表化等設計，在減少磁盤I/O次數、穩定查詢性能、高效支持范圍查詢和排序操作等方面取得了最佳平衡。盡管在某些特定場景下（如純等值查詢），哈希索引可能更快，但B+樹憑借其全面而均衡的優秀特性，成為了關系型數據庫索引事實上的標準解決方案，為現代數據處理和存儲服務提供了堅實可靠的基礎。