相信很多人對於MySQL的索引都不陌生，索引(Index)是幫助MySQL高效獲取數據的數據結構。
因為索引是MySQL中比較重點的知識，相信很多人都有一定的瞭解，尤其是在面試中出現的頻率特別高。樓主自認為自己對MySQL的索引相關知識有很多瞭解，而且因為最近在找工作面試，所以單獨複習了很多關於索引的知識。
但是，我還是圖樣圖森破，直到我被阿里的面試官虐過之後我才知道，自己在索引方面的知識，只是個小學生水平。
以下，是我總結的一次阿里面試中關於索引有關的問題以及知識點。
一、索引概念、索引模型
我們是怎麼聊到索引的呢，是因為我提到我們的業務量比較大，每天大概有幾百萬的新數據生成，於是有了以下對話：
Q1：你們每天這麼大的數據量，都是保存在關係型數據庫中嗎？
A：是的，我們線上使用的是MySQL數據庫 。
Q2：每天幾百萬數據，一個月就是幾千萬了，那你們有沒有對於查詢做一些優化呢？
A：我們在數據庫中創建了一些索引（我現在非常後悔我當時說了這句話）。
這裡可以看到，阿里的面試官並不會像有一些公司一樣拿著題庫一道一道的問，而是會根據面試者做過的事情以及面試過程中的一些內容進行展開。
Q3：那你能說說什麼是索引嗎？
A：（這道題肯定難不住我啊）索引其實是一種數據結構，能夠幫助我們快速的檢索數據庫中的數據。
Q4：那麼索引具體採用的哪種數據結構呢？
A：（這道題我也背過）常見的MySQL主要有兩種結構：Hash索引和B+ Tree索引，我們使用的是InnoDB引擎，默認的是B+樹。
這裡我耍了一個小心機，特意說了一下索引和存儲引擎有關。希望面試官可以問我一些關於存儲引擎的問題。然而面試官並沒有被我帶跑...
Q5：既然你提到InnoDB使用的B+ 樹的索引模型，那麼你知道為什麼採用B+ 樹嗎？這和Hash索引比較起來有什麼優缺點嗎？
A：（突然覺得這道題有點難，但是我還是憑藉著自己的知識儲備簡單的回答上一些）因為Hash索引底層是哈希表，哈希表是一種以key-value存儲數據的結構，所以多個數據在存儲關係上是完全沒有任何順序關係的，所以對於區間查詢是無法直接通過索引查詢的，就需要全表掃描。所以，哈希索引只適用於等值查詢的場景。而B+ 樹是一種多路平衡查詢樹，所以他的節點是天然有序的（左子節點小於父節點、父節點小於右子節點），所以對於範圍查詢的時候不需要做全表掃描。
Q6：除了上面這個範圍查詢的，你還能說出其他的一些區別嗎？
A：（這個題我回答的不好，事後百度了一下。）
B+Tree索引和Hash索引區別？
哈希索引適合等值查詢，但是無法進行範圍查詢；
哈希索引沒辦法利用索引完成排序 ；
哈希索引不支持多列聯合索引的最左匹配規則；
如果有大量重複鍵值的情況下，哈希索引的效率會很低，因為存在哈希碰撞問題。
二、聚簇索引、覆蓋索引
Q1：剛剛我們聊到B+ Tree ，那你知道B+ Tree的葉子節點都可以存哪些東西嗎？
A：InnoDB的B+ Tree可能存儲的是整行數據，也有可能是主鍵的值。
Q2：那這兩者有什麼區別嗎？
A：（當他問我葉子節點的時候，其實我就猜到他可能要問我聚簇索引和非聚簇索引了）在 InnoDB 裡，索引B+ Tree的葉子節點存儲了整行數據的是主鍵索引，也被稱之為聚簇索引。而索引B+ Tree的葉子節點存儲了主鍵的值的是非主鍵索引，也被稱之為非聚簇索引。
Q3：那麼，聚簇索引和非聚簇索引，在查詢數據的時候有區別嗎？
A：聚簇索引查詢會更快？
Q4：為什麼呢？
A：因為主鍵索引樹的葉子節點直接就是我們要查詢的整行數據了。而非主鍵索引的葉子節點是主鍵的值，查到主鍵的值以後，還需要再通過主鍵的值再進行一次查詢。
Q5：剛剛你提到主鍵索引查詢只會查一次，而非主鍵索引需要回表查詢多次。（後來我才知道，原來這個過程叫做回表）是所有情況都是這樣的嗎？非主鍵索引一定會查詢多次嗎？
A：（額、這個問題我回答的不好，後來我自己查資料才知道，通過覆蓋索引也可以只查詢一次。）
覆蓋索引（covering index）指一個查詢語句的執行只用從索引中就能夠取得，不必從數據表中讀取。也可以稱之為實現了索引覆蓋。
當一條查詢語句符合覆蓋索引條件時，MySQL只需要通過索引就可以返回查詢所需要的數據，這樣避免了查到索引後再返回表操作，減少I/O提高效率。
如，表covering_index_sample中有一個普通索引 idx_key1_key2(key1,key2)。
當我們通過SQL語句：select key2 from covering_index_sample where key1 = 'keytest';的時候，就可以通過覆蓋索引查詢，無需回表。
三、聯合索引、最左前綴匹配
Q1：不知道的話沒關係，想問一下，你們在創建索引的時候都會考慮哪些因素呢？
A：我們一般對於查詢概率比較高，經常作為where條件的字段設置索引。
Q2：那你們有用過聯合索引嗎？
A：用過呀，我們有對一些表中創建過聯合索引。
Q3：那你們在創建聯合索引的時候，需要做聯合索引多個字段之間順序你們是如何選擇的呢？
A：我們把識別度最高的字段放到最前面。
Q4：為什麼這麼做呢？
A：（這個問題有點把我問蒙了，稍微有些慌亂）這樣的話可能命中率會高一點吧......
Q5：那你知道最左前綴匹配嗎？
A：（我突然想起來原來面試官是想問這個，怪自己剛剛為什麼就沒想到這個呢。）哦哦哦。您剛剛問的是這個意思啊，在創建多列索引時，我們根據業務需求，where子句中使用最頻繁的一列放在最左邊，因為MySQL索引查詢會遵循最左前綴匹配的原則，即最左優先，在檢索數據時從聯合索引的最左邊開始匹配。所以當我們創建一個聯合索引的時候，如(key1,key2,key3)，相當於創建了（key1）、(key1,key2)和(key1,key2,key3)三個索引，這就是最左匹配原則。
雖然我一開始有點懵，沒有聯想到最左前綴匹配，但是面試官還是引導了我，很友善。
四、索引下推、查詢優化
Q1：你們線上用的MySQL是哪個版本呢？
A：我們MySQL是5.7。
Q2：那你知道在MySQL 5.6中，對索引做了哪些優化嗎？
A：不好意思，這個我沒有去了解過。（事後我查了一下，有一個比較重要的 ：Index Condition Pushdown Optimization。）
Index Condition Pushdown（索引下推）
MySQL 5.6引入了索引下推優化，默認開啟，使用SET optimizer_switch = 'index_condition_pushdown=off';可以將其關閉。官方文檔中給的例子和解釋如下：
people表中（zipcode，lastname，firstname）構成一個索引
SELECT * FROM people WHERE zipcode='95054' AND lastname LIKE '%etrunia%' AND address LIKE '%Main Street%';
如果沒有使用索引下推技術，則MySQL會通過zipcode='95054'從存儲引擎中查詢對應的數據，返回到MySQL服務端，然後MySQL服務端基於lastname LIKE '%etrunia%'和address LIKE '%Main Street%'來判斷數據是否符合條件。
如果使用了索引下推技術，則MYSQL首先會返回符合zipcode='95054'的索引，然後根據lastname LIKE '%etrunia%'和address LIKE '%Main Street%'來判斷索引是否符合條件。如果符合條件，則根據該索引來定位對應的數據，如果不符合，則直接reject掉。有了索引下推優化，可以在有like條件查詢的情況下，減少回表次數。
Q3：你們創建的那麼多索引，到底有沒有生效，或者說你們的SQL語句有沒有使用索引查詢你們有統計過嗎？
A：這個還沒有統計過，除非遇到慢SQL的時候我們才會去排查 。
Q4：那排查的時候，有什麼手段可以知道有沒有走索引查詢呢？
A：可以通過explain查看SQL語句的執行計劃，通過執行計劃來分析索引使用情況。
Q5：那什麼情況下會發生明明創建了索引，但是執行的時候並沒有通過索引呢？
A：（大概記得和優化器有關，但是這個問題並沒有回答好。）
查詢優化器
一條SQL語句的查詢，可以有不同的執行方案，至於最終選擇哪種方案，需要通過優化器進行選擇，選擇執行成本最低的方案。
在一條單表查詢語句真正執行之前，MySQL的查詢優化器會找出執行該語句所有可能使用的方案，對比之後找出成本最低的方案。
這個成本最低的方案就是所謂的執行計劃。優化過程大致如下：
根據搜索條件，找出所有可能使用的索引；
計算全表掃描的代價；
計算使用不同索引執行查詢的代價；
對比各種執行方案的代價，找出成本最低的那一個。
Q6：哦，索引有關的知識我們暫時就問這麼多吧。你們線上數據的事務隔離級別是什麼呀？
A：(後面關於事務隔離級別的問題了，就不展開了。)
感覺是因為我回答的不夠好，如果這幾個索引問題我都會的話，他還會追問更多，恐怕會被虐的更慘。
五、總結&感悟
以上，就是一次面試中關於索引部分知識的問題以及我整理的答案。感覺這次面試過程中關於索引的知識，自己大概能夠回答的內容佔70%左右，但是自信完全答對的內容只佔50%左右，看來自己索引有關的知識瞭解的還是不夠多。
通過這次面試，發現像阿里這種大廠對於底層知識還是比較看重的，我以前以為關於索引最多也就問一下Hash和B+有什麼區別，沒想到最後都能問到查詢優化器上面。
最後，不管本次面試能不能通過，都非常感謝有這樣一次機會，可以讓自己看到自己的不足。通過這次面試，我也收穫了很多東西。加油！
>>>>
參考資料
極客時間 -《MySQL實戰45講》
掘金小冊 -《MySQL 是怎樣運行的：從根兒上理解 MySQL》
博文視點 -《高性能MySQL》
作者：Hollis
來源：Java之道（ID：javaways）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
"