索引的本質
MySQL官方對於索引的定義為：索引是幫助MySQL高效獲取數據的數據結構。即可以理解為：索引是數據結構。
我們知道，數據庫查詢是數據庫最主要的功能之一，我們都希望查詢數據的速度盡可能的快，因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找，當然這種時間復雜度為O(n)的算法在數據量很大時顯然是糟糕的，於是有了二分查找、二叉樹查找等。但是二分查找要求被檢索數據有序，而二叉樹查找只能應用於二叉查找樹，但是數據本身的組織結構不可能完全滿足各種數據結構。所以，在數據之外，數據庫系統還維護者滿足特定查找算法的數據結構，這些數據結構以某種方式引用數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。
B-Tree和B+Tree
目前大部分數據庫系統及文件系統都采用B-Tree和B+Tree作為索引結構。
索引
索引的目的：提高查詢效率
原理：通過不斷的縮小想要獲得數據的范圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是我們總是通過同一種查找方式來鎖定數據。
數據結構：B+樹
圖解B+樹與查找過程：
如上圖，是一顆b+樹，關於b+樹的定義可以參見B+樹，這里只說一些重點，淺藍色的塊我們稱之為一個磁盤塊，可以看到每個磁盤塊包含幾個數據項（深藍色所示）和指針（黃色所示），如磁盤塊1包含數據項17和35，包含指針P1、P2、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項，如17、35並不真實存在於數據表中。
b+樹的查找過程
如圖所示，如果要查找數據項29，那么首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找確定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間因為非常短（相比磁盤的IO）可以忽略不計，通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，通過指針加載磁盤塊8到內存，發生第三次IO，同時內存中做二分查找找到29，結束查詢，總計三次IO。真實的情況是，3層的b+樹可以表示上百萬的數據，如果上百萬的數據查找只需要三次IO，性能提高將是巨大的，如果沒有索引，每個數據項都要發生一次IO，那么總共需要百萬次的IO，顯然成本非常非常高。
b+樹性質
通過上面的分析，我們知道IO次數取決於b+數的高度h，假設當前數據表的數據為N，每個磁盤塊的數據項的數量是m，則有h=㏒(m+1)N，當數據量N一定的情況下，m越大，h越小；而m = 磁盤塊的大小 / 數據項的大小，磁盤塊的大小也就是一個數據頁的大小，是固定的，如果數據項占的空間越小，數據項的數量越多，樹的高度越低。這就是為什么每個數據項，即索引字段要盡量的小，比如int占4字節，要比bigint8字節少一半。這也是為什么b+樹要求把真實的數據放到葉子節點而不是內層節點，一旦放到內層節點，磁盤塊的數據項會大幅度下降，導致樹增高。當數據項等於1時將會退化成線性表。