索引的目的在於提高查詢效率，可以類比字典，如果要查“mysql”這個單詞，我們肯定需要定位到m字母，然後從下往下找到y字母，再找到剩下的sql。如果沒有索引，那麽妳可能需要把所有單詞看壹遍才能找到妳想要的，如果我想找到m開頭的單詞呢？或者ze開頭的單詞呢？是不是覺得如果沒有索引，這個事情根本無法完成？
索引原理
除了詞典，生活中隨處可見索引的例子，如火車站的車次表、圖書的目錄等。它們的原理都是壹樣的，通過不斷的縮小想要獲得數據的範圍來篩選出最終想要的結果，同時把隨機的事件變成順序的事件，也就是我們總是通過同壹種查找方式來鎖定數據。
數據庫也是壹樣，但顯然要復雜許多，因為不僅面臨著等值查詢，還有範圍查詢(>、<、between、in)、模糊查詢(like)、並集查詢(or)等等。數據庫應該選擇怎麽樣的方式來應對所有的問題呢？我們回想字典的例子，能不能把數據分成段，然後分段查詢呢？最簡單的如果1000條數據，1到100分成第壹段，101到200分成第二段，201到300分成第三段……這樣查第250條數據，只要找第三段就可以了，壹下子去除了90%的無效數據。但如果是1千萬的記錄呢，分成幾段比較好？稍有算法基礎的同學會想到搜索樹，其平均復雜度是lgN，具有不錯的查詢性能。但這裏我們忽略了壹個關鍵的問題，復雜度模型是基於每次相同的操作成本來考慮的，數據庫實現比較復雜，數據保存在磁盤上，而為了提高性能，每次又可以把部分數據讀入內存來計算，因為我們知道訪問磁盤的成本大概是訪問內存的十萬倍左右，所以簡單的搜索樹難以滿足復雜的應用場景。
索引的數據結構
前面講了生活中索引的例子，索引的基本原理，數據庫的復雜性，又講了操作系統的相關知識，目的就是讓大家了解，任何壹種數據結構都不是憑空產生的，壹定會有它的背景和使用場景，我們現在總結壹下，我們需要這種數據結構能夠做些什麽，其實很簡單，那就是：每次查找數據時把磁盤IO次數控制在壹個很小的數量級，最好是常數數量級。那麽我們就想到如果壹個高度可控的多路搜索樹是否能滿足需求呢？就這樣，b+樹應運而生。