前言
之前在網上看到過很多關於mysql聯合索引最左前綴匹配的文章，自以爲就瞭解了其原理，最近面試時和大牛交流中，發現遺漏了些東西，這裏自己整理一下這方面的內容。
最左前綴匹配原則
在mysql建立聯合索引時會遵循最左前綴匹配的原則，即最左優先，在檢索數據時從聯合索引的最左邊開始匹配，
示例：
CREATE TABLE `student` (
`Id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增Id',
`Gid` int(11) unsigned DEFAULT NULL COMMENT '年級id',
`Cid` int(11) unsigned DEFAULT NULL COMMENT '班級id',
`SId` int(11) unsigned DEFAULT NULL COMMENT '學號',
`Name` varchar(10) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT '姓名',
PRIMARY KEY (`Id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
對列Gid、列Cid和列Sid建一個聯合索引
create unique index uni_Gid_Cid_SId on student(Gid,Cid,SId)
聯合索引 uni_Gid_Cid_SId 實際建立了(Gid)、(Gid,Cid)、(Gid,Cid,SId)三個索引。
插入模擬數據
INSERT INTO `student` (`Gid`, `Cid`, `SId`, `Name`) VALUES (floor(rand() * rand() *rand() * 1000000000) , floor(rand() * rand() *rand() * 1000000000) , floor(rand() * rand() * rand() *1000000000) , rand());
查詢實例：
SELECT * FROM student WHERE Gid=68778 AND Cid=465176354 AND Name='0.56437948'
上面這個查詢語句執行時會依照最左前綴匹配原則，檢索時會使用索引(Gid,Cid)進行數據匹配。
注意
索引的字段可以是任意順序的，如：
SELECT * FROM student WHERE Gid=68778 AND Cid=465176354 ;
SELECT * FROM student WHERE Cid=465176354 AND Gid=68778;
這兩個查詢語句都會用到索引(Gid,Cid)，mysql創建聯合索引的規則是首先會對聯合合索引的最左邊的，也就是第一個字段Gid的數據進行排序，在第一個字段的排序基礎上，然後再對後面第二個字段Cid進行排序。其實就相當於實現了類似 order by Gid Cid這樣一種排序規則。
有人會疑惑第二個查詢語句不符合最左前綴匹配：首先可以肯定是兩個查詢語句都保函索引(Gid,Cid)中的Gid、Cid兩個字段，只是順序不一樣，查詢條件一樣，最後所查詢的結果肯定是一樣的。既然結果是一樣的，到底以何種順序的查詢方式最好呢？此時我們可以藉助mysql查詢優化器explain，explain會糾正sql語句該以什麼樣的順序執行效率最高，最後才生成真正的執行計劃。
那麼問題產生了？既然結果是一樣的，到底以何種順序的查詢方式最好呢？
所以，而此時那就是我們的mysql查詢優化器該登場了，sql語句中字段的順序不需要和聯合索引中定義的字段順序一致，查詢優化器會自己調整順序，mysql查詢優化器會判斷糾正這條sql語句該以什麼樣的順序執行效率最高，最後才生成真正的執行計劃。所以，當然是我們能儘量的利用到索引時的查詢順序效率最高咯，所以mysql查詢優化器會最終以這種順序進行查詢執行。
爲什麼要使用聯合索引
減少開銷。建一個聯合索引(Gid,Cid,SId)，實際相當於建了(Gid)、(Gid,Cid)、(Gid,Cid,SId)三個索引。每多一個索引，都會增加寫操作的開銷和磁盤空間的開銷。對於大量數據的表，使用聯合索引會大大的減少開銷！
覆蓋索引。對聯合索引(Gid,Cid,SId)，如果有如下的sql: select Gid,Cid,SId from student where Gid=1 and Cid=2。那麼MySQL可以直接通過遍歷索引取得數據，而無需回表，這減少了很多的隨機io操作。減少io操作，特別的隨機io其實是dba主要的優化策略。所以，在真正的實際應用中，覆蓋索引是主要的提升性能的優化手段之一。
效率高。索引列越多，通過索引篩選出的數據越少。有1000W條數據的表，有如下sql:select from table where Gid=1 and Cid=2 and SId=3,假設假設每個條件可以篩選出10%的數據，如果只有單值索引，那麼通過該索引能篩選出1000W10%=100w條數據，然後再回表從100w條數據中找到符合Gid=2 and Cid= 3的數據，然後再排序，再分頁；如果是聯合索引，通過索引篩選出1000w10% 10% *10%=1w，效率提升可想而知！
缺點。聯合索引越多，索引列越多，則創建的索引越多，索引都是存儲在磁盤裏的，通過索引算法(Btree代表索引算法使用二叉樹的形式來做索引的)來查找數據，的確可以極大的提高查詢效率，但是與此同時增刪改的同時，需要更新索引，同樣是需要花時間的，並且索引所佔的磁盤空間也不小。
建議。單表儘可能不要超過一個聯合索引，單個聯合索引不超過3個字段。
引申
對於聯合索引(Gid,Cid,SId)，查詢語句SELECT * FROM student WHERE Cid = 465176354 ;是否能夠觸發索引？
大多數人都會說NO，實際上卻是YES。
原因：
EXPLAIN SELECT * FROM student WHERE SId=465176354;
EXPLAIN SELECT * FROM student WHERE Gid=68778
觀察上述兩個explain結果中的type字段。查詢中分別是：
index：這種類型表示mysql會對整個該索引進行掃描。要想用到這種類型的索引，對這個索引並無特別要求，只要是索引，或者某個聯合索引的一部分，mysql都可能會採用index類型的方式掃描。但是呢，缺點是效率不高，mysql會從索引中的第一個數據一個個的查找到最後一個數據，直到找到符合判斷條件的某個索引。所以，上述語句會觸發索引。
ref：這種類型表示mysql會根據特定的算法快速查找到某個符合條件的索引，而不是會對索引中每一個數據都進行一一的掃描判斷，也就是所謂你平常理解的使用索引查詢會更快的取出數據。而要想實現這種查找，索引卻是有要求的，要實現這種能快速查找的算法，索引就要滿足特定的數據結構。簡單說，也就是索引字段的數據必須是有序的，才能實現這種類型的查找，才能利用到索引。
總結
以上所述是給大家介紹的mysql聯合索引最左匹配原則，希望對大家有所幫助