共計 3885 個字符，預計需要花費 10 分鐘才能閱讀完成。
本篇內容介紹了“MySQL 索引最左匹配原則是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
準備
為了方面后續的說明，我們首先建立一個如下的表（MySQL5.7），表中共有 5 個字段（a、b、c、d、e），其中 a 為主鍵，有一個由 b，c，d 組成的聯合索引，存儲引擎為 InnoDB，插入三條測試數據。強烈建議自己在 MySQL 中嘗試本文的所有語句。
CREATE TABLE `test` (
`a` int NOT NULL AUTO_INCREMENT,
`b` int DEFAULT NULL,
`c` int DEFAULT NULL,
`d` int DEFAULT NULL,
`e` int DEFAULT NULL,
PRIMARY KEY(`a`),
KEY `idx_abc` (`b`,`c`,`d`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
INSERT INTO test(`a`, `b`, `c`, `d`, `e`) VALUES (1, 2, 3, 4, 5);
INSERT INTO test(`a`, `b`, `c`, `d`, `e`) VALUES (2, 2, 3, 4, 5);
INSERT INTO test(`a`, `b`, `c`, `d`, `e`) VALUES (3, 2, 3, 4, 5);這時候，我們如果執行下面這個 SQL 語句，你覺得會走索引嗎？
SELECT b, c, d FROM test WHERE d = 2;如果你按照最左匹配原則（簡述為在聯合索引中，從最左邊的字段開始匹配，若條件中字段在聯合索引中符合從左到右的順序則走索引，否則不走，可以簡單理解為 (a, b, c) 的聯合索引相當于創建了 a 索引、(a, b)索引和 (a, b, c) 索引），這句顯然是不符合這個規則的，它走不了索引，但是我們用 EXPLAIN 語句分析，會發現一個很有趣的現象，它的輸出如下是使用了索引的。
這就很奇怪了，最左匹配原則失效了嗎？事實上，并沒有，我們一步步來分析。
理論詳解
由于現在基本上以 InnoDB 引擎為主，我們以 InnoDB 為例進行主要說明。
聚集索引和非聚集索引
MySQL 底層使用 B + 樹來存儲索引，數據均存在葉子節點上。對于 InnoDB 而言，主鍵索引和行記錄時存儲在一起的，因此叫做聚集索引（clustered index）。除了聚集索引，其他所有都叫做非聚集索引（secondary index），包括普通索引、唯一索引等。
在 InnoDB 中，只存在一個聚集索引：
若表存在主鍵，則主鍵索引就是聚集索引；
若表不存在主鍵，則會把第一個非空的唯一索引作為聚集索引；
否則，會隱式定義一個 rowid 作為聚集索引。
我們以下圖為例，假設現在有一個表，存在 id、name、age 三個字段，其中 id 為主鍵，因此 id 為聚集索引，name 建立索引為非聚集索引。關于 id 和 name 的索引，有如下的 B + 樹，可以看到，聚集索引的葉子節點存儲的是主鍵和行記錄，非聚集索引的葉子節點存儲的是主鍵。
回表查詢
從上面的索引存儲結構來看，我們可以看到，在主鍵索引樹上，通過主鍵就可以一次性查出我們所需要的數據，速度很快。這很直觀，因為主鍵就和行記錄存儲在一起，定位到了主鍵就定位到了所要找的包含所有字段的記錄。
但是對于非聚集索引，如上面的右圖，我們可以看到，需要先根據 name 所在的索引樹找到對應主鍵，然后通過主鍵索引樹查詢到所要的記錄，這個過程叫做回表查詢。
索引覆蓋
上面的回表查詢無疑會降低查詢的效率，那么有沒有辦法讓它不回表呢？這就是索引覆蓋。所謂索引覆蓋，就是說，在使用這個索引查詢時，使它的索引樹的葉子節點上的數據可以覆蓋你查詢的所有字段，就可以避免回表了。我們回到一開始的例子，我們建立的 (b,c,d) 的聯合索引，因此當我們查詢的字段在 b、c、d 中的時候，就不會回表，只需要查看一次索引樹，這就是索引覆蓋。
最左匹配原則
指的是聯合索引中，優先走最左邊列的索引。對于多個字段的聯合索引，也同理。如 index(a,b,c) 聯合索引，則相當于創建了 a 單列索引，(a,b)聯合索引，和 (a,b,c) 聯合索引。
我們可以執行下面的幾條語句驗證一下這個原則。
EXPLAIN SELECT * FROM test WHERE b = 1;EXPLAIN SELECT * FROM test WHERE b = 1 and c = 2;EXPLAIN SELECT * FROM test WHERE b = 1 and c = 2 and d = 3;接著，我們嘗試一條不符合最左原則的查詢，它也如圖預期一樣，走了全表掃描。
EXPLAIN SELECT * FROM test WHERE d = 3;詳細規則
我們先來看下面兩個語句，他們的輸出如下。
EXPLAIN SELECT b, c from test WHERE b = 1 and c = 1;
EXPLAIN SELECT b, d from test WHERE d = 1;id|select_type|table|partitions|type|possible_keys|key |key_len|ref |rows|filtered|Extra |
--+-----------+-----+----------+----+-------------+-------+-------+-----------+----+--------+-----------+
1|SIMPLE |test | |ref |idx_bcd |idx_bcd|10 |const,const| 1| 100.0|Using index|
d|select_type|table|partitions|type |possible_keys|key |key_len|ref|rows|filtered|Extra |
--+-----------+-----+----------+-----+-------------+-------+-------+---+----+--------+------------------------+
1|SIMPLE |test | |index|idx_bcd |idx_bcd|15 | | 3| 33.33|Using where; Using index|顯然第一條語句是符合最左匹配的，因此 type 為 ref，但是第二條并不符合最左匹配，但是也不是全表掃描，這是因為此時這表示掃描整個索引樹。
具體來看，index 代表的是會對整個索引樹進行掃描，如例子中的，列 d，就會導致掃描整個索引樹。ref 代表 mysql 會根據特定的算法查找索引，這樣的效率比 index 全掃描要高一些。但是，它對索引結構有一定的要求，索引字段必須是有序的。而聯合索引就符合這樣的要求，聯合索引內部就是有序的，你可以理解為 order by b,c,d 這種排序規則，先根據字段 b 排序，再根據字段 c 排序，以此類推。這也解釋了，為什么需要遵守最左匹配原則，當最左列有序才能保證右邊的索引列有序。
因此，我們總結最后的原則為，若符合最左覆蓋原則，則走 ref 這種索引；若不符合最左匹配原則，但是符合覆蓋索引（index），就可以掃描整個索引樹，從而找到覆蓋索引對應的列，避免回表；若不符合最左匹配原則，也不符合覆蓋索引（如本例的 select *），則需要掃描整個索引樹，并且回表查詢行記錄，此時，查詢優化器認為這樣兩次查找索引樹，還不如全表掃描來得快（因為聯合索引此時不符合最左匹配原則，要不普通索引查詢慢得多），因此，此時會走全表掃描。
補充：為什么要使用聯合索引
減少開銷。建一個聯合索引 (col1,col2,col3)，實際相當于建了(col1),(col1,col2),(col1,col2,col3) 三個索引。每多一個索引，都會增加寫操作的開銷和磁盤空間的開銷。對于大量數據的表，使用聯合索引會大大的減少開銷！
覆蓋索引。對聯合索引(col1,col2,col3)，如果有如下的 sql: select col1,col2,col3 from test where col1=1 and col2=2。那么 MySQL 可以直接通過遍歷索引取得數據，而無需回表，這減少了很多的隨機 io 操作。減少 io 操作，特別的隨機 io 其實是 dba 主要的優化策略。所以，在真正的實際應用中，覆蓋索引是主要的提升性能的優化手段之一。
效率高。索引列越多，通過索引篩選出的數據越少。有 1000W 條數據的表，有如下 sql:select from table where col1=1 and col2=2 and col3=3, 假設假設每個條件可以篩選出 10% 的數據，如果只有單值索引，那么通過該索引能篩選出 1000W10%=100w 條數據，然后再回表從 100w 條數據中找到符合 col2=2 and col3= 3 的數據，然后再排序，再分頁；如果是聯合索引，通過索引篩選出 1000w10% 10% *10%=1w，效率提升可想而知！
“MySQL 索引最左匹配原則是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！
