我猜題主執行計劃裡面一定是 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吧。
我猜題主執行計劃裡面一定是 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吧。