b+樹索引是目前關係型資料庫系統中查詢最為常用和最為有效的索引。
b+樹索引並不能找到乙個給定鍵的具體行，b+樹索引能找到的只是被查詢資料行所在的頁，然後資料庫通過把頁讀入到記憶體，再在記憶體中進行查詢，最後得到要查詢的資料。
由二叉樹演變而來是b樹的變種。
在b+樹中，所有記錄節點都是按鍵值的大小順序存放在同一層的葉子節點上，由各葉子節點指標進行連線。
不同索引中的b+樹結構
聚集索引
如上圖所示的b+樹結構，在mysql資料庫中，對於聚集索引的b+樹結構，在index page中存放的就是表中的主鍵值和指標，對於leaf page存放的就是當前頁中按照主鍵索引排列好的數資料記錄。
輔助索引
但是對於輔助索引，mysql在index page中存放的是輔助索引
的鍵值和指標，在leaf page中存放的則是輔助索引對應的主鍵的值和乙個書籤（bookmark），該書籤用來高速innodb儲存引擎**可以找到與索引相對應的行資料，其實就是相應行資料的聚集索引鍵。
舉個例子：如果在一棵高度為3的輔助索引樹中查詢資料，那需要對這棵輔助索引樹遍歷3次找到指定主鍵，如果聚集索引樹的高度同樣為3，那麼還需要對聚集索引樹進行3次查詢，最終找到乙個完整的行資料所在的頁。因此一共需要6次邏輯io訪問以得到最終的乙個資料頁。
找到一張很形象的圖：
聯合索引
聯合索引本質上也是一棵b+樹，不同的是聯合索引的鍵值的數量不是1，而是大於等於2。舉例如下：
create
table t(
a int
, b int
,primary
key(a)
,key idx_a_b(a,b)
)engine
=innodb
還從網上找了一張比較形象的圖：
在聯合索引中的index page中存放的是聯合索引的所有鍵值，但是在index page中只是以聯合索引最左邊的鍵值進行排序的，直到葉子節點leaf page中每個記錄排序則以聯合索引之後的幾個鍵值依次進行排序，最終通過聯合索引找到主鍵的值進行查詢。這也是為什麼聯合索引要遵循**最左字首原則**
聯合索引中當第一列鍵值已經確定時，它會對之後的鍵值進行排序處理。比如（a,b），在a相同的情況下的所有記錄中，b已經是拍好序的。這個時候如果執行 select * from t where t.a=1 order by b;
執行explain發現，innodb並沒有使用主鍵索引，而是直接使用了聯合索引，這樣可以少一次查詢。
覆蓋索引
覆蓋索引是從輔助索引中就可以得到查詢的記錄，而不需要查詢聚集索引中的記錄。也就是select的列恰好都是被輔助索引覆蓋的列，這樣查詢時就只需要查詢索引索引頁就能直接得到結果而不需要再去讀取主鍵索引頁了，同時輔助索引頁中不包含全部的記錄資訊，只有索引資訊，所以每頁可以讀取更多的索引記錄，這樣讀取到的頁次數就少了，綜上的原因覆蓋索引可以大量的減少io操作，提高查詢效能。
這裡只總結一下插入和刪除操作的不同情況。不再詳細介紹
插入
刪除
MySQL索引 B 樹結構
b 樹在資料庫中的應用 1.檔案很大，不可能全部儲存在記憶體中，故要儲存到磁碟上 2.索引的結構組織要儘量減少查詢過程中磁碟i o的訪問次數 為什麼使用b tree，還跟磁碟訪問原理有關。3.區域性性原理與磁碟預讀，預讀的長度一般為頁 page 的整倍數，在許多作業系統中，頁得大小通常為4k 4.資...
MySQL索引B 樹結構
b 樹在資料庫中的應用 1.檔案很大，不可能全部儲存在記憶體中，故要儲存到磁碟上 2.索引的結構組織要儘量減少查詢過程中磁碟i o的訪問次數 為什麼使用b tree，還跟磁碟訪問原理有關。3.區域性性原理與磁碟預讀，預讀的長度一般為頁 page 的整倍數，在許多作業系統中，頁得大小通常為4k 4.資...
資料庫索引為什麼B樹結構
這是乙個很深的問題，我採用逐步問答的方式來解答。試圖用最簡潔的語言解決整體概念上的問題。本文目的純粹是提供對 索引採用b樹結構 這個問題的一種入門概念，不涉及深入的東西。資料庫索引為什麼會選擇b樹結構？答 因為使用b樹查詢時，所用的磁碟io操作次數比平衡二叉樹更少，效率也更高。為什麼使用b樹查詢所用...