B+樹索引是目前關係型數據庫系統中查找最爲常用和最爲有效的索引。
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
表t中在列a和列b上建立了聯合索引idx_a_b，他的索引的結構如下圖：
還從網上找了一張比較形象的圖：
在聯合索引中的Index page中存放的是聯合索引的所有鍵值，但是在Index page中只是以聯合索引最左邊的鍵值進行排序的，直到葉子節點Leaf Page中每個記錄排序則以聯合索引之後的幾個鍵值依次進行排序，最終通過聯合索引找到主鍵的值進行查詢。這也是爲什麼聯合索引要遵循**最左前綴原則**
聯合索引中當第一列鍵值已經確定時，它會對之後的鍵值進行排序處理。比如（a,b），在a相同的情況下的所有記錄中，b已經是拍好序的。這個時候如果執行 select * from t where t.a=1 order by b;
執行explain發現，innodb並沒有使用主鍵索引，而是直接使用了聯合索引，這樣可以少一次查詢。
覆蓋索引
覆蓋索引是從輔助索引中就可以得到查詢的記錄，而不需要查詢聚集索引中的記錄。也就是select的列恰好都是被輔助索引覆蓋的列，這樣查詢時就只需要查詢索引索引頁就能直接得到結果而不需要再去讀取主鍵索引頁了，同時輔助索引頁中不包含全部的記錄信息，只有索引信息，所以每頁可以讀取更多的索引記錄，這樣讀取到的頁次數就少了，綜上的原因覆蓋索引可以大量的減少io操作，提高查詢性能。
B+樹的插入和刪除操作
這裏只總結一下插入和刪除操作的不同情況。不再詳細介紹
插入
刪除
