mysql復合索引需要匹配最左列嗎？

我猜題主執行計劃里面一定是 possibile_key是null而key是有索引吧！其實看key來判斷有無使用索引是不準確的，優化器不是神它只能大概的反應一下情況而已。眾所周知，innodb的索引是基于B+樹的，所以才會有最左前綴這個概念（在這里就不簡述B+樹的概念了）。那么為什么會出現題主這種情況呢？其實在mysql中有一個覆蓋索引的概念。什么意思呢？也就是說在一個查詢中返回的列 都 都 都 包含在復合索引的時候就是覆蓋索引，此時搜索引擎會直接返回B+樹的節點頁上的數據（也就是索引的數據），此時效率是最高的。跑題了，在使用explain的時候，如果你的返回列全是包含在復合索引中的時候就會出現 possibile_key為null而key不為空的情況，但是你會發現rows的數量會無敵大，幾乎是全表掃描，索引根本不起用！看圖例子！

我創建了一個3列的表，前兩列組成復合索引，并插入100W條數據。

此時我們照題主的sql來分析一下，題主只用第二列

看到那個rows了嗎？？？雖然key有我們創建的索引的名字，但是rows幾乎是整張表的行數，也就是說要查詢這條數據基本是全表掃描的！索引基本沒用！因為我們是要返回name這一列的，但是這一列是包含在復合索引中的，所以會出現覆蓋索引的情況，才會出現possibile_key為null而key不為空！沒圖我說個j八？

看到區別了嗎？sex不在復合索引中，所以key是null；id 在復合索引中key不為空；但是id,sex 不全 不全 不全 在復合索引中，所以沒有達到索引覆蓋的情況，key為null；id,name 全 全 全 在復合索引中，所以key不為空。但是它們的rows都是幾乎和全表的數據一樣多，所以索引根本不起用！再來給你看下索引起效的例子：

看ref看rows!!

看吧，沒騙你吧？老實人是不會騙人的。能解決你的疑惑就雙擊666吧。