3.1 索引基礎
索引（在MySQL中也叫做“鍵（key）”）是儲存引擎用於快速找到記錄的一種資料結構。
3.1.1 索引基礎----B+ Tree 原理
1. 資料結構
B Tree 指的是 Balance Tree，也就是平衡樹。平衡樹是一顆查詢樹，並且所有葉子節點位於同一層。
B+ Tree 是基於 B Tree 和葉子節點順序訪問指標進行實現，它具有 B Tree 的平衡性，並且通過順序訪問指標來提高區間查詢的效能。
在 B+ Tree 中，一個節點中的 key 從左到右非遞減排列，如果某個指標的左右相鄰 key 分別是 keyi 和 keyi+1，且不為 null，則該指標指向節點的所有 key 大於等於 keyi 且小於等於 keyi+1。
2. 操作
進行查詢操作時，首先在根節點進行二分查詢，找到一個 key 所在的指標，然後遞迴地在指標所指向的節點進行查詢。直到查詢到葉子節點，然後在葉子節點上進行二分查詢，找出 key 所對應的 data。
插入刪除操作會破壞平衡樹的平衡性，因此在插入刪除操作之後，需要對樹進行一個分裂、合併、旋轉等操作來維護平衡性。
3. 與紅黑樹的比較
紅黑樹等平衡樹也可以用來實現索引，但是檔案系統及資料庫系統普遍採用 B+ Tree 作為索引結構，主要有以下兩個原因：
（一）更少的查詢次數
平衡樹查詢操作的時間複雜度等於樹高 h，而樹高大致為 O(h)=O(logdN)，其中 d 為每個節點的出度。
紅黑樹的出度為 2，而 B+ Tree 的出度一般都非常大，所以紅黑樹的樹高 h 很明顯比 B+ Tree 大非常多，查詢的次數也就更多。
（二）利用磁碟預讀特性
為了減少磁碟 I/O，磁碟往往不是嚴格按需讀取，而是每次都會預讀。預讀過程中，磁碟進行順序讀取，順序讀取不需要進行磁碟尋道，並且只需要很短的旋轉時間，速度會非常快。
作業系統一般將記憶體和磁碟分割成固態大小的塊，每一塊稱為一頁，記憶體與磁碟以頁為單位交換資料。資料庫系統將索引的一個節點的大小設定為頁的大小，使得一次 I/O 就能完全載入一個節點。並且可以利用預讀特性，相鄰的節點也能夠被預先載入。
3.1.2 索引的型別
在MySQL中，索引是在儲存引擎層實現的，而不是在伺服器層實現的，所以不同儲存引擎具有不同的索引型別和實現。
1. B+Tree 索引
是大多數 MySQL 儲存引擎的預設索引型別。當人們談論索引的時候，如果沒有特別指明型別，那多半說的就是B-Tree索引，它使用B-Tree資料結構來儲存資料。其中InnoDB使用B+Tree資料結構。
B-Tree索引能夠加快訪問資料的速度，因為儲存引擎不再需要進行全表掃描來獲取需要的資料，只需要對樹進行搜尋即可，所以查詢速度快很多。
除了用於查詢，還可以用於排序和分組。
可以指定多個列作為索引列，多個索引列共同組成鍵。
表中的每一行資料，索引中包含了last_name、first_name和dob列的值，下圖顯示了該索引是如果組織資料的儲存的。
注意，索引對多個值進行排序的依據是CREATE TABLE語句中定義索引時列的順序。
可以使用B-Tree索引的查詢型別。適用於全鍵值、鍵值範圍或鍵字首查詢，其中鍵字首查詢只適用於最左字首查詢。如果不是按照索引列的順序進行查詢，則無法使用索引。
全值匹配：
全值匹配指的是和索引中的所有列進行匹配，例如前面提到的索引可用於查詢姓名為Cuba Allen 、出生於1960-01-01的人。
匹配最左字首：
前面提到的索引可用於查詢所有姓為Allen的人，即只使用索引的第一列。
匹配列字首：
也可以只匹配某一列的值的的開頭部分。例如前面提到的索引可用於查詢所有以J開頭的姓的人。這裡也只使用了索引的第一列。
匹配範圍值：
例如前面提到的索引可用於查詢姓在Allen和Barrymore之間的人。這裡也只使用了索引的第一列。
精確匹配某一列並範圍匹配另外一列：
前面提到的索引也可用於查詢所有姓為Allen，並且名字是K開頭的人。即第一列last_name全匹配，第二例first_name範圍匹配。
只訪問索引的查詢：
查詢只需要訪問索引，而無需訪問資料行。
InnoDB 的 B+Tree 索引分為主索引和輔助索引。主索引的葉子節點 data 域記錄著完整的資料記錄，這種索引方式被稱為聚簇索引。因為無法把資料行存放在兩個不同的地方，所以一個表只能有一個聚簇索引。
輔助索引的葉子節點的 data 域記錄著主鍵的值，因此在使用輔助索引進行查詢時，需要先查詢到主鍵值，然後再到主索引中進行查詢。
2. 雜湊索引
雜湊索引能以 O(1) 時間進行查詢，但是失去了有序性：
- 無法用於排序與分組；
- 只支援精確查詢和等值比較查詢，無法用於部分查詢和範圍查詢，因為雜湊索引始終是使用索引列的全部內容來計算雜湊值的。
InnoDB 儲存引擎有一個特殊的功能叫“自適應雜湊索引”，當某個索引值被使用的非常頻繁時，會在 B+Tree 索引之上再建立一個雜湊索引，這樣就讓 B+Tree 索引具有雜湊索引的一些優點，比如快速的雜湊查詢。
3. 空間資料索引
MyISAM 儲存引擎支援空間資料索引（R-Tree），可以用於地理資料儲存。與B-Tree索引不同，這類索引無需淺醉查詢。空間資料索引會從所有維度來索引資料，可以有效地使用任意維度來進行組合查詢。
必須使用 GIS 相關的函式來維護資料。
4. 全文索引
MyISAM 儲存引擎支援全文索引，用於查詢文字中的關鍵詞，而不是直接比較是否相等。
查詢條件使用 MATCH AGAINST，而不是普通的 WHERE。
全文索引使用倒排索引實現，它記錄著關鍵詞到其所在文件的對映。
InnoDB 儲存引擎在 MySQL 5.6.4 版本中也開始支援全文索引。
3.1.3 索引的優點
-
大大減少了伺服器需要掃描的資料行數。
-
幫助伺服器避免進行排序和分組，以及避免建立臨時表（B+Tree 索引是有序的，可以用於 ORDER BY 和 GROUP BY 操作。臨時表主要是在排序和分組過程中建立，因為不需要排序和分組，也就不需要建立臨時表）。
-
將隨機 I/O 變為順序 I/O（B+Tree 索引是有序的，會將相鄰的資料都儲存在一起）。
3.1.4 高效能的索引策略
1. 獨立的列
在進行查詢時，索引列不能是表示式的一部分，也不能是函式的引數，否則無法使用索引。
例如下面的查詢不能使用 actor_id 列的索引：
SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;
2. 多列索引
在需要使用多個列作為條件進行查詢時，使用多列索引比使用多個單列索引效能更好。例如下面的語句中，最好把 actor_id 和 film_id 設定為多列索引。
SELECT film_id, actor_ id FROM sakila.film_actor WHERE actor_id = 1 AND film_id = 1;
3. 索引列的順序
讓選擇性最強的索引列放在前面。
索引的選擇性是指：索引的選擇性是指，不重複的索引值（也稱為基數，cardinality）和資料表的記錄總數（#T）的比值，範圍從1/#T到1之間，此時每個記錄都有唯一的索引與其對應。選擇性越高，查詢效率也越高。
例如下面顯示的結果中 customer_id 的選擇性比 staff_id 更高，因此最好把 customer_id 列放在多列索引的前面。
SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity, COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity, COUNT(*) FROM payment;
staff_id_selectivity: 0.0001 customer_id_selectivity: 0.0373 COUNT(*): 16049
4. 字首索引和索引選擇性
對於 BLOB、TEXT 和 VARCHAR 型別的列，必須使用字首索引，只索引開始的部分字元。一般情況下某個列字首的選擇性也是足夠高的，足以滿足查詢效能。
對於字首長度的選取需要根據索引選擇性來確定。
5. 覆蓋索引
索引確實是一種查詢資料的高效方式，但是MySQL也可以使用索引來直接獲取列的資料，這樣就不再需要讀取資料行。如果索引包含所有需要查詢的欄位的值，我們就稱之為“覆蓋索引”。
具有以下優點：
- 索引條目通常遠小於資料行的大小，只讀取索引能大大減少資料訪問量。
- 因為索引是按照列值順序儲存的，所以 對於I/O密集型的範圍查詢會比隨機從磁碟讀取每一行資料的I/O要少得多。
- 一些儲存引擎（例如 MyISAM）在記憶體中只快取索引，而資料依賴於作業系統來快取。因此，只訪問索引可以不使用系統呼叫（通常比較費時）。
- 由於 InnoDB 的聚簇索引，覆蓋索引對InnoDB特別有用。若輔助索引能夠覆蓋查詢，則無需訪問主索引。
3.1.4 索引的使用條件
-
對於非常小的表、大部分情況下簡單的全表掃描比建立索引更高效；
-
對於中到大型的表，索引就非常有效；
-
但是對於特大型的表，建立和維護索引的代價將會隨之增長。這種情況下，需要用到一種技術可以直接區分出需要查詢的一組資料，而不是一條記錄一條記錄地匹配，例如可以使用分割槽技術。