首先，正確的創(chuàng)建合適的索引，是提升數(shù)據(jù)庫查詢性能的基礎。

索引是什么？

索引是為了加速對表中數(shù)據(jù)行的檢索而創(chuàng)建的一種分散存儲的數(shù)據(jù)結構。

索引的工作機制是怎樣的？

如上圖中，如果現(xiàn)在有一條sql語句 select * from teacher where id = 101，如果沒有索引的條件下，我們要找到這條記錄，我們就需要就行全表掃描，匹配id = 101的數(shù)據(jù)。如果有了索引，我們就可以快速的通過索引找到101所對應的行記錄在磁盤中的地址，再根據(jù)給定的地址取出對應的行數(shù)據(jù)。

MYSQL數(shù)據(jù)庫為什么要使用B+TREE作為索引的數(shù)據(jù)結構？

對數(shù)據(jù)的加速檢索，首先想到的就是二叉樹，二叉樹的查找時間復雜度可以達到O(log2(n))。下面看一下二叉樹的存儲結構：

二叉樹搜索相當于一個二分查找。二叉查找能大大提升查詢的效率，但是它有一個問題：二叉樹以第一個插入的數(shù)據(jù)作為根節(jié)點，如上圖中，如果只看右側，就會發(fā)現(xiàn)，就是一個線性鏈表結構。如果我們現(xiàn)在的數(shù)據(jù)只包含1, 2, 3, 4，5, 6，就會出現(xiàn)一下情況：

如果我們要查詢的數(shù)據(jù)為6則需要遍歷所有的節(jié)點才能找到6，即，相當于全表掃描，就是由于存在這種問題，所以二叉查找樹不適合用于作為索引的數(shù)據(jù)結構。

基于這樣的推演，為了解決存在線性鏈表的問題，很容易就能夠想到平衡二叉查找樹。下面看看平衡二叉樹是怎樣的：

平衡二叉查找樹定義為：節(jié)點的子節(jié)點高度差不能超過1,如上圖中的節(jié)點20，左節(jié)點高度為1，右節(jié)點高度0，差為1，所以上圖沒有違反定義，他就是一個平衡二叉樹。保證二叉樹平衡的方式為左旋，右旋等操作，至于如果左旋右旋，可以自行去搜索相關的知識。

如果上圖中平衡二叉樹保存的是id索引，現(xiàn)在要從id = 8的數(shù)據(jù)，首先要把根節(jié)點加載進內(nèi)存，用8和10進行比較，發(fā)現(xiàn)8比10小，繼續(xù)加載10的左子樹。把5加載進內(nèi)存，用8和5比較，同理，加載5節(jié)點的右子樹。此時發(fā)現(xiàn)命中，現(xiàn)在要加載id為8的索引對應的數(shù)據(jù)。

怎么找到索引對應的數(shù)據(jù)呢？

索引保存數(shù)據(jù)的方式一般有兩種，第一種為在節(jié)點的數(shù)據(jù)區(qū)保存id = 8的行數(shù)據(jù)的所有數(shù)據(jù)具體內(nèi)容。另外一種方式，數(shù)據(jù)區(qū)保存的是真正保存數(shù)據(jù)的磁盤地址。

到這里，平衡二叉樹解決了存在線性鏈表的問題，數(shù)據(jù)查詢的效率好像也還可以，基本能達到O(log2(n))， 那為什么mysql不選擇這樣的數(shù)據(jù)結構呢，他又存在什么樣的問題呢？

問題1： 搜索效率不足，一般來說，在樹結構中，數(shù)據(jù)所處的深度，決定了搜索時的IO次數(shù)。如上圖中搜索id = 8的數(shù)據(jù)，需要進行3次IO。當數(shù)據(jù)量到達幾百萬的時候，樹的高度就會很恐怖。

問題2： 查詢不不穩(wěn)定，如果查詢的數(shù)據(jù)落在根節(jié)點，只需要一次IO，如果是葉子節(jié)點或者是支節(jié)點，會需要多次IO才可以。

問題3： 節(jié)點存儲的數(shù)據(jù)內(nèi)容太少。沒有很好利用操作系統(tǒng)和磁盤數(shù)據(jù)交換特性，也沒有利用好磁盤IO的預讀能力。因為操作系統(tǒng)和磁盤之間一次數(shù)據(jù)交換是已頁為單位的，一頁 = 4K，即每次IO操作系統(tǒng)會將4K數(shù)據(jù)加載進內(nèi)存。但是，在二叉樹每個節(jié)點的結構只保存一個關鍵字，一個數(shù)據(jù)區(qū)，兩個子節(jié)點的引用，并不能夠填滿4K的內(nèi)容。幸幸苦苦做了一次的IO操作，卻只加載了一個關鍵字，在樹的高度很高，恰好又搜索的關鍵字位于葉子節(jié)點或者支節(jié)點的時候，取一個關鍵字要做很多次的IO。

那有沒有一種結構能夠解決二叉樹的這種問題呢？

有，多路平衡查找樹：（Balance Tree）：

B Tree 是一個絕對平衡樹，所有的葉子節(jié)點在同一高度，如下圖所示：

B Tree有什么優(yōu)勢，又是怎么去解決一些問題的呢？

先看定義，上圖為一個2-3樹（每個節(jié)點存儲2個關鍵字，有3路），多路平衡查找樹也就是多叉的意思，從上圖中可以看出，每個節(jié)點保存的關鍵字的個數(shù)和路數(shù)關系為：

關鍵字個數(shù) = 路數(shù) – 1。

假設要從上圖中去尋找id = 28的數(shù)據(jù)，B TREE 搜索過程如下：

首先把根節(jié)點加載進內(nèi)存，加載了17,35兩個關鍵字，判斷規(guī)則為：

根據(jù)以上規(guī)則命中28后，接下來加載28對應的數(shù)據(jù)， 就去找28對應的數(shù)據(jù)區(qū)，數(shù)據(jù)區(qū)中存儲的是具體的數(shù)據(jù)或者是指向數(shù)據(jù)的指針。

為什么說這種結構能夠解決平衡二叉樹存在的問題呢？

能夠很好的利用操作系統(tǒng)和磁盤的交互特性， MYSQL為了很好的利用磁盤的預讀能力，將頁大小為16K，即將一個節(jié)點（磁盤塊）的大小設置為16K，一次IO將一個節(jié)點（16K）內(nèi)容加載進內(nèi)存。這里，假設關鍵字類型為 int，即4字節(jié)，若每個關鍵字對應的數(shù)據(jù)區(qū)也為4字節(jié)，不考慮子節(jié)點引用的情況下，則上圖中的每個節(jié)點大約能夠存儲（16 * 1000）/ 8 = 2000個關鍵字，則共2001個路數(shù)。對于二叉樹，三層高度，最多可以保存7個關鍵字，而對于這種有2001路的B樹，三層高度能夠搜索的關鍵字個數(shù)遠遠的大于二叉樹。

在B TREE保證樹的平衡的過程中，每次關鍵字的變化，都會導致結構發(fā)生很大的變化，這個過程是特別浪費時間的，所以創(chuàng)建索引一定要創(chuàng)建合適的索引，而不是把所有的字段都創(chuàng)建索引，創(chuàng)建冗余索引只會在對數(shù)據(jù)進行新增，刪除，修改時增加性能消耗。

既然B樹已經(jīng)很好的解決了問題，為什么MYSQL還要用B+TREE？

先看看B+TREE是怎樣的，B+TREE是B TREE的一個變種，在B+樹種，B樹種的路數(shù)和關鍵字的個數(shù)的關系不再成立了，B+TREE中，數(shù)據(jù)檢索規(guī)則采用的是左閉合區(qū)間，路數(shù)和關鍵個數(shù)關系為1比1，具體如下圖所示：

如果上圖中是用ID做的索引，如果是搜索id = 1的數(shù)據(jù)，搜索規(guī)則如下：

根據(jù)如上規(guī)則，最終在葉子節(jié)點中命中數(shù)據(jù)，根據(jù)葉子節(jié)點中節(jié)點1的數(shù)據(jù)區(qū)取得真正的數(shù)據(jù)。

B TREE和B+TREE區(qū)別是什么？

1、B+TREE 關鍵字的搜索采用的是左閉合區(qū)間，之所以采用左閉合區(qū)間是因為他要最好的去支持自增id，這也是mysql的設計初衷。即，如果id = 1命中，會繼續(xù)往下查找，直到找到葉子節(jié)點中的1。

2、B+TREE 根節(jié)點和支節(jié)點沒有數(shù)據(jù)區(qū)，關鍵字對應的數(shù)據(jù)只保存在葉子節(jié)點中。即只有葉子節(jié)點中的關鍵字數(shù)據(jù)區(qū)才會保存真正的數(shù)據(jù)內(nèi)容或者是內(nèi)容的地址。而在B樹種，如果根節(jié)點命中，則會直接返回數(shù)據(jù)。并且在B+TREE中，葉子節(jié)點不會去保存子節(jié)點的引用。

3、B+TREE葉子節(jié)點是順序排列的，并且相鄰的節(jié)點具有順序引用的關系，如上圖中葉子節(jié)點之間有指針相連接。

MYSQL為什么最終要去選擇B+TREE？

1、B+TREE是B TREE的變種，B TREE能解決的問題，B+TREE也能夠解決（降低樹的高度，增大節(jié)點存儲數(shù)據(jù)量）

2、 B+TREE掃庫和掃表能力更強，如果我們要根據(jù)索引去進行數(shù)據(jù)表的掃描，對B TREE進行掃描，需要把整棵樹遍歷一遍，而B+TREE只需要遍歷他的所有葉子節(jié)點即可（葉子節(jié)點之間有引用）。

3、B+TREE磁盤讀寫能力更強，他的根節(jié)點和支節(jié)點不保存數(shù)據(jù)區(qū)，所有根節(jié)點和支節(jié)點同樣大小的情況下，保存的關鍵字要比B TREE要多。而葉子節(jié)點不保存子節(jié)點引用。所以，B+TREE讀寫一次磁盤加載的關鍵字比B TREE