上篇文章已經簡單介紹了Mysql索引的基本介紹，這篇文章主要講解一下所以的實現原理。索引的定義其實非常復雜，嚴格的定義需要用到關系代數的概念，不在咱們討論范圍內，這里咱們只討論mysql的常用的引擎的索引，以及這些引擎為什么要選擇B+Tree？
索引的本質
MySQL官方對索引的定義為：索引（Index）是幫助MySQL高效獲取數據的數據結構。提取句子主干，就可以得到索引的本質：索引是數據結構。
我們知道，數據庫查詢是數據庫的最主要功能之一。我們都希望查詢數據的速度能盡可能的快，因此數據庫系統的設計者會從查詢算法的角度進行優化。最基本的查詢算法當然是順序查找（linear search），這種復雜度為O(n)的算法在數據量很大時顯然是糟糕的，好在計算機科學的發展提供了很多更優秀的查找算法，例如二分查找（binary search）、二叉樹查找（binary tree search）等。如果稍微分析一下會發現，每種查找算法都只能應用於特定的數據結構之上，例如二分查找要求被檢索數據有序，而二叉樹查找只能應用於二叉查找樹上，但是數據本身的組織結構不可能完全滿足各種數據結構（例如，理論上不可能同時將兩列都按順序進行組織），所以，在數據之外，數據庫系統還維護着滿足特定查找算法的數據結構，這些數據結構以某種方式引用（指向）數據，這樣就可以在這些數據結構上實現高級查找算法。這種數據結構，就是索引。
圖1展示了一種可能的索引方式。左邊是數據表，一共有兩列七條記錄，最左邊的是數據記錄的物理地址（注意邏輯上相鄰的記錄在磁盤上也並不是一定物理相鄰的）。為了加快Col2的查找，可以維護一個右邊所示的二叉查找樹，每個節點分別包含索引鍵值和一個指向對應數據記錄物理地址的指針，這樣就可以運用二叉查找在O(log2n)O(log2n)的復雜度內獲取到相應數據。
雖然這是一個貨真價實的索引，但是實際的數據庫系統幾乎沒有使用二叉查找樹或其進化品種紅黑樹（red-black tree）實現的，原因會在下文介紹。
一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對於內存存取，I/O存取的消耗要高幾個數量級，所以評價一個數據結構作為索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進復雜度。換句話說，索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數。
為了達到這個目的，磁盤按需讀取，要求每次都會預讀的長度一般為頁的整數倍。而且數據庫系統將一個節點的大小設為等於一個頁，這樣每個節點只需要一次I/O就可以完全載入。每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁里，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。並把B-tree中的m值設的非常大，就會讓樹的高度降低，有利於一次完全載入
B-tree的原理
B+tree的原理
B-tree和B+tree的區別
Mysql為何選擇B+Tree？
MYISAM和InnoDB的區別
學習鏈接