MySQL索引原理

什麼是索引？

「索引」是爲了可以更快地查詢數據。好比一本書的目錄，就是這本書的內容的索引，讀者能夠經過在目錄中快速查找本身想要的內容，而後根據頁碼去找到具體的章節。

數據庫也是同樣，若是查詢語句使用到了索引，會先去索引裏面查詢，取得數據所在行的物理地址，進而訪問數據。

索引的優缺點

優點：以快速檢索，減小I/O次數，加快檢索速度；根據索引分組和排序，能夠加快分組和排序；

劣勢：索引自己也是表，所以會佔用存儲空間。索引的維護和建立須要時間成本，這個成本隨着數據量增大而增大；構建索引會下降數據表的修改操做（刪除，添加，修改）的效率，由於在修改數據表的同時還須要修改索引表。

索引的分類

在MySQL中，常見的索引類型有：主鍵索引、惟一索引、普通索引、全文索引、組合索引。建立語法分別爲：

其中，組合索引又稱爲多列索引，上述代碼中最後一個例子就是創建了3列的索引。MySQL在根據索引查詢時，會遵循「最左匹配」原則，即先根據col1的條件查，再根據col2的條件查，而後再根據col3的條件去查。

若是跳過了一個列直接查後面的列，好比下面的語句，就不能使用上面建立的索引了：

這裏有一個小技巧，若是你前面的列是一個簡單的枚舉類型，好比性別等，能夠用在where語句中加 col1 in(MALE, FEMALE) 來「跳過」 col1 列，並使用上述索引。

對於某列若是是字符串且比較長（好比UUID），推薦使用前綴索引，即匹配前n個字符。具體這個n取值多少是根據你的數據來的，《高性能MySQL》裏提供了一個技巧：經過使用LEFT函數查詢，從1開始，不斷增長n的值，直到查詢結果的行數接近完整列的查詢結果的行數，就是合適的n的值。

索引的實現原理

MySQL的索引是由存儲引擎來實現的。因爲存儲引擎不一樣，因此具備不一樣的索引類型，如BTree索引，B+Tree索引，哈希索引，全文索引等。這裏因爲主要介紹BTree索引和B+Tree索引，咱們平時使用最多的InnoDB引擎就是基於B+Tree索引的。

目前版本的MySQL InnoDB引擎已經支持全文索引，但不支持中文，能夠經過使用ngram插件開始支持中文。

從二叉搜索樹聊起

瞭解過數據結構的朋友應該知道一種叫二叉樹的數據結構。二叉樹根據用途不一樣，衍生了不一樣的變種，好比堆，好比二叉搜索樹。

而二叉搜索樹中，爲了防止極端狀況樹的高度過大影響查詢效率，因此衍生出了一些平衡二叉查找樹，最典型的就是AVL和紅黑樹。

但二叉樹在數據量較大時，深度過深，不太適合數據庫的查詢，因此數據庫使用了多叉樹。

BTree

BTree（又稱爲B-Tree）是一個平衡搜索多叉樹。BTree的結構以下圖：

設樹的度爲2d（d>1），高度爲h，那麼BTree有如下性質：

• 每一個葉子結點的高度同樣，等於h；
• 每一個非葉子結點由n-1個key和n個指針組成，key和指針相互隔離，結點兩端必定是key；
• 葉子結點指針爲null；
• 非葉子結點的key都是[key,data]二元組，其中key表示做爲索引的鍵，data爲鍵值所在行的其它列的數據；

在BTree中，對索引列是順序存儲的，因此很適合查找範圍數據和ORDER BY操做。

B+Tree

B+Tree是BTree的一種變種。B+Tree和BTree的不一樣主要在於：

• B+Tree中的非葉子結點不存儲數據，只存儲鍵值；
• B+Tree的葉子結點沒有指針，全部鍵值都會出如今葉子結點上，且key存儲的鍵值對應data數據的物理地址；
• B+Tree的每一個非葉子節點由n個鍵值key和n個指針point組成；

結構圖：

B+Tree對比BTree的優勢：

通常來講B+Tree比BTree更適合實現外存的索引結構，由於存儲引擎的設計專家巧妙的利用了外存（磁盤）的存儲結構。

磁盤的最小存儲單位是扇區（sector），而操做系統的塊（block）一般是整數倍的sector，操做系統以頁（page）爲單位管理內存，一頁（page）一般默認爲4K，數據庫的頁一般設置爲操做系統頁的整數倍，所以索引結構的節點被設計爲一個頁的大小，而後利用外存的「預讀取」原則，每次讀取的時候，把整個節點的數據讀取到內存中，而後在內存中查找。

已知內存的讀取速度是外存讀取I/O速度的幾百倍，那麼提高查找速度的關鍵就在於儘量少的磁盤I/O，那麼能夠知道，每一個節點中的key個數越多，那麼樹的高度越小，須要I/O的次數越少，所以通常來講B+Tree比BTree更快，由於B+Tree的非葉節點中不存儲data，就能夠存儲更多的key。

帶順序索引的B+Tree

通常在數據庫系統或文件系統中使用的B+Tree結構都在經典B+Tree的基礎上進行了優化，增長了順序訪問指針。

在B+Tree的每一個葉子節點增長一個指向相鄰葉子節點的指針，就造成了帶有順序訪問指針的B+Tree。作這個優化的目的是爲了提升區間訪問的性能，例如若是要查詢key爲從18到49的全部數據記錄，當找到18後，只需順着節點和指針順序遍歷就能夠一次性訪問到全部數據節點，不用從頭再查詢一次，極大提到了區間查詢效率。

聚簇索引和非聚簇索引

MySQL中最多見的兩種存儲引擎分別是MyISAM和InnoDB，分別實現了非聚簇索引和聚簇索引。

前段時間看到一個問題：「你知道爲何InnoDB非主鍵索引廣泛比主鍵索引要慢嗎？」答案是InnoDB使用了聚簇索引，主鍵索引主須要查詢一次，而非主鍵索引須要查詢兩次。

爲何非主鍵索引須要查詢兩次呢？且看接下來的內容。

主索引與輔助索引

首先介紹一下基礎的概念。在索引的分類中，咱們能夠按照索引的鍵是否爲主鍵來分爲「主索引」和「輔助索引」，使用主鍵鍵值創建的索引稱爲「主索引」，其它的稱爲「輔助索引」。所以主索引只能有一個，輔助索引能夠有不少個。

爲何須要用到輔助索引？由於前面咱們介紹了，查詢語句若是想要使用索引，是須要知足最左匹配原則的。有時候咱們的查詢並不會使用到主鍵列，因此須要在其它列創建索引，即輔助索引。

非聚簇索引

非聚簇索引的主索引和輔助索引幾乎是同樣的，只是主索引不容許重複，不容許空值，他們的葉子結點的key都存儲指向鍵值對應的數據的物理地址。

非聚簇索引的數據表和索引表是分開存儲的。非聚簇索引中的數據是根據數據的插入順序保存。所以非聚簇索引更適合單個數據的查詢。插入順序不受鍵值影響。

聚簇索引

聚簇索引的主索引的葉子結點存儲的是鍵值對應的數據自己，輔助索引的葉子結點存儲的是鍵值對應的數據的主鍵鍵值。所以主鍵的值長度越小越好，類型越簡單越好。

聚簇索引的數據和主鍵索引存儲在一塊兒。

聚簇索引的數據是根據主鍵的順序保存。所以適合按主鍵索引的區間查找，能夠有更少的磁盤I/O，加快查詢速度。可是也是由於這個緣由，聚簇索引的插入順序最好按照主鍵單調的順序插入，不然會頻繁的引發頁分裂（BTree插入時的一個操做），嚴重影響性能。

在InnoDB中，若是隻須要查找索引的列，就儘可能不要加入其它的列，這樣會提升查詢效率。

一張圖說明聚簇索引與非聚簇索引的區別：