概覽
索引是一種資料結構，用於幫助我們在大量資料中快速定位到我們想要查詢的資料。
索引好比一本好書的目錄頁，需要查詢某個章節直接在目錄頁查詢，然後開啟響應頁數。
但索引也不是就快，如果章節少，那就直接翻開書找即可很快找到，只有章節非常多時，我們就可以利用索引快速找到。
所以，如果想讓索引發揮出其真正的實力，需要在資料量大之時才可放心使用索引，反之就是大材小用。
MySQL 中索引分類
- B + 樹索引
- Hash 索引
- 全文索引
以下篇幅會以 InnoDB 儲存引擎為例分析 B+ 樹索引。
在此之前，看下 B+ 樹 的演化：
二叉樹
如上圖中展示，商品表建立了一個二叉樹查詢的索引。
圖中可以看到二叉樹的節點，節點中儲存了鍵（key）和資料（data）；鍵對應商品表中的 id，資料對應商品表中的行資料。
二叉樹特性：任何節點的左子節點的鍵值都小於當前節點的鍵值，右子節點的鍵值都大於當前節點的鍵值；頂端的節點為根節點，沒有子節點的節點為葉子節點。
若現在要查詢 id = 12 的商品資訊，透過建立的二叉樹索引，查詢流程如下：
- 將根節點作為當前節點，把 12 與當前節點的鍵值 10 比較，12 大於 10，接下來把當前節點的右子節點作為當前節點，也就是 13
- 把 12 和當前節點的鍵值 13 比較，發現 12 小於 13，把當前節點的左子節點作為當前節點，也就是 12
- 把 12 和當前節點的鍵值 12 比較，12 等於 12，滿足條件，從當前節點取出 data，即 id = 12，name = xm
透過二叉樹查詢需要 3 次即可找到匹配的資料；若在表中一條一條的查詢，需要 6 次才可以找到。
平衡二叉樹
二叉樹若是以上這樣的結構，就變成了連結串列。
現在要查詢 id = 17 的商品資訊，需要查詢 7 次，也就是相當於全表掃描；導致這樣的原因主要是二叉樹查詢變得不平衡了，即：高度太高了，從而致使查詢效率不穩定。
so，為了保證二叉樹一直保持平衡，就要用到平衡二叉樹呢。
平衡二叉樹（AVL 樹），在滿足二叉查詢樹特性的基礎上，要求每個節點的左右子樹的高度差不能超過 1。如下為平衡二叉樹與非平衡二叉樹的比較圖：
平衡二叉樹保證了樹的構造是保持平衡的，當插入或刪除資料導致不滿足平衡二叉樹不平衡時，平衡二叉樹會進行調整樹上的節點來保持平衡。
B 樹
資料在記憶體中存放是不可靠的，實際中會將例如商品表中的資料和索引儲存在磁碟中；但磁碟相較於記憶體，讀取資料的速度會慢上千百倍，所以應該儘量減少從磁碟中讀取資料的次數；還有從磁碟讀取資料時，都是按照磁碟塊讀取的，並不是一條記錄一條記錄讀的；如果能將資料放進磁碟塊中，那麼一次磁碟讀取操作就會讀取更多的資料，超找資料的時間就會減低。如果用樹這種資料結構作為索引的資料結構，那麼每次查詢資料就只需要從磁碟中讀取一個節點（磁碟塊）。而平衡二叉樹每個節點只儲存一個鍵值和資料，這樣每個磁碟塊就只能存一個鍵值和資料，大量資料儲存的情況，就會出現二叉樹節點多，高度高，導致查詢資料進行的磁碟 IO 次數也隨之變多，以至於查詢資料的效率極具降低。如下圖所示：
為了解決平衡二叉樹的這個弊端，我們應該尋找一種單個節點可以儲存多個鍵值和資料的平衡樹，而 B 樹就滿足這種情況。
B 樹（Balance Tree）即為平衡樹的意思，如下是一個 B 樹：
圖中的 p 節點為指向子節點的指標。
圖中的每個節點稱為頁，頁就是我們上面說的磁碟塊，在 MySQL 中資料讀取的基本單位都是頁。
從上圖可以看出，B 樹相對於平衡二叉樹，每個節點儲存了更多的鍵值（key）和資料（data），並且每個節點擁有更多的子節點，子節點的個數一般稱為階，上述圖中的 B 樹為 3 階 B 樹，高度也會很低。
基於這個特性，B 樹查詢資料讀取磁碟的次數將會很少，資料的查詢效率也會比平衡二叉樹高很多。
假如我們要查詢 id=28 的使用者資訊，那麼我們在上圖 B 樹中查詢的流程如下：
- 先找到根節點也就是頁 1，判斷 28 在鍵值 17 和 35 之間，那麼我們根據頁 1 中的指標 p2 找到頁 3
- 將 28 和頁 3 中的鍵值相比較，28 在 26 和 30 之間，我們根據頁 3 中的指標 p2 找到頁 8
- 將 28 和頁 8 中的鍵值相比較，發現有匹配的鍵值 28，鍵值 28 對應的使用者資訊為（28，bv）
B+ 樹
B+ 樹與 B 樹區別：
-
B+ 樹非葉子節點上是不儲存資料的，僅儲存鍵值，而 B 樹節點中不僅儲存鍵值，也會儲存資料。之所以這麼做是因為在資料庫中頁的大小是固定的，InnoDB 中頁的預設大小是 16KB。
如果不儲存資料，那麼就會儲存更多的鍵值，相應的樹的階數（節點的子節點樹）就會更大，樹就會更矮更胖，如此一來我們查詢資料進行磁碟的 IO 次數又會再次減少，資料查詢的效率也會更快。
另外，B+ 樹的階數是等於鍵值的數量的，如果我們的 B+ 樹一個節點可以儲存 1000 個鍵值，那麼 3 層 B+ 樹可以儲存 1000×1000×1000=10 億個資料。
一般根節點是常駐記憶體的，所以一般我們查詢 10 億資料，只需要 2 次磁碟 IO。 -
因為 B+ 樹索引的所有資料均儲存在葉子節點，而且資料是按照順序排列的。
那麼 B+ 樹使得範圍查詢，排序查詢，分組查詢以及去重查詢變得異常簡單。而 B 樹因為資料分散在各個節點，要實現這一點是很不容易的。
B+ 樹中各個頁之間是透過雙向連結串列連線的，葉子節點中的資料是透過單向連結串列連線的。
其實上面的 B 樹我們也可以對各個節點加上鍊表。這些不是它們之前的區別，是因為在 MySQL 的 InnoDB 儲存引擎中，索引就是這樣儲存的。也就是說上圖中的 B+ 樹索引就是 InnoDB 中 B+ 樹索引真正的實現方式，準確的說應該是聚集索引。
透過上圖可以看到，在 InnoDB 中，我們透過資料頁之間透過雙向連結串列連線以及葉子節點中資料之間透過單向連結串列連線的方式可以找到表中所有的資料。
MyISAM 中的 B+ 樹索引實現與 InnoDB 中的略有不同。在 MyISAM 中，B+ 樹索引的葉子節點並不儲存資料，而是儲存資料的檔案地址。
跳錶
聚集索引&非聚集索引
在 MySQL 中，B+ 樹索引按照儲存方式的不同分為聚集索引和非聚集索引。
只說 InnoDB 中的聚集索引和非聚集索引：
-
聚集索引（聚簇索引）：以 InnoDB 作為儲存引擎的表，表中的資料都會有一個主鍵，即使你不建立主鍵，系統也會幫你建立一個隱式的主鍵。
這是因為 InnoDB 是把資料存放在 B+ 樹中的，而 B+ 樹的鍵值就是主鍵，在 B+ 樹的葉子節點中，儲存了表中所有的資料。
這種以主鍵作為 B+ 樹索引的鍵值而構建的 B+ 樹索引，我們稱之為聚集索引。 -
非聚集索引（非聚簇索引）：以主鍵以外的列值作為鍵值構建的 B+ 樹索引，我們稱之為非聚集索引。非聚集索引與聚集索引的區別在於非聚集索引的葉子節點不儲存表中的資料，而是儲存該列對應的主鍵，想要查詢資料我們還需要根據主鍵再去聚集索引中進行查詢，這個再根據聚集索引查詢資料的過程，稱為回表。
聚集索引查詢資料
以上是一個聚集索引。
假設查詢 id >= 18 並且 id < 40 的使用者資料。對應的 sql 語句為：
select * from user where id >= 18 and id < 40
id 是主鍵，查詢過程如下：
- 根節點一般情況下是在記憶體中，即：頁 1 已存在於記憶體中，此時不需要到磁碟中讀取資料，直接在記憶體中讀取；
從記憶體彙總讀取到頁 1，要查詢這個 id >= 18 and id < 40 的範圍值，首先要找到 id = 18的鍵值；
從頁 1 中可以找到鍵值 18，此時需要根據指標 p2，定位到頁 3； - 從頁 3 中查詢資料，就需要用 p2 指標去磁碟中進行讀取頁 3；
從磁碟中讀取頁 3 後將 頁 3 放入記憶體中，然後進行查詢，看可以找到鍵值 18，之後拿到頁 3 中的指標 p1，定位到頁 8； - 同樣的頁 8 不存在記憶體中，需要從磁碟中將頁 8 讀取進記憶體中；
將頁 8 讀取到記憶體中後，頁中的資料是連結串列進行連結的，而且鍵值是按照順序存放，可以根據二分查詢法定位到鍵值 18；
此時已經找到資料頁，同時也找到了滿足 id = 18 的資料，即：鍵值 18 對應的資料；
因是範圍查詢，而且此時所有的資料又都存在葉子節點，並且是有序排列的，因此，可以對頁 8 中的鍵值依次遍歷查詢並匹配滿足條件的資料；
一直遍歷查詢，找到鍵值為 22 的資料，之後頁 8 中就沒有資料了，此時需要用頁 8 中的 p 指標去讀取頁 9 中的資料； - 而頁 9 不在記憶體中，就又會載入頁 9 到記憶體中，並透過和頁 8 中一樣的方式進行資料的查詢（遍歷、p 指標），知道將頁 12 載入到記憶體中，發現 41 大於 40，這時就不滿足條件了，結束查詢。
- 最終我們找到滿足條件的所有資料，總共 12 條記錄：
(18,kl), (19,kl), (22,hj), (24,io), (25,vg) , (29,jk), (31,jk) , (33,rt) , (34,ty) , (35,yu) , (37,rt) , (39,rt)
查詢詳情流程圖：
非聚集索引查詢資料
非聚簇索引會根據二級索引找到主鍵，之後，拿著主鍵回表查詢（和聚簇索引流程一致）；
減少回表查詢
索引覆蓋
一個查詢可以完全透過索引來執行，無需訪問實際的資料行。即：一個索引包含了需要查詢的所有欄位 -> 聯合索引
索引下推可以避免回表
儘可能把查詢條件推到索引層面進行過濾，減少從磁碟讀取的資料量。但是 ta 依賴於儲存引擎層面