一般情況下，我們會在一個索引上較多的使用等值查詢或者范圍查詢，此時索引大多可以幫助我們極快的查詢出我們需要的數據。

那當我們在where條件中對索引列使用!=查詢，索引還能發揮他的作用嗎？

以此SQL為例：

select * from t where k != 6;

MySQL會如何執行這個SQL呢？是直接全表掃描嗎？

其實，走不走索引，只取決于一個因素，那就是成本。

我們知道，MySQL中有一個叫做優化器的東西，他會對每一條查詢sql做成本分析，然后根據分析結果選擇是否使用索引或者全表掃描。

對于上面的sql，優化器會將k!=6轉化為兩個區間查詢(-∞，6)和(6，+∞)，然后對索引樹進行成本計算。

我們畫一個簡略版的二級索引樹。

簡單解釋一下：每個顏色代表一個數據頁（MySQL與磁盤交互是以頁為單位，默認一個頁是16kb，這里我們假設一個頁存兩條數據，并且MySQL規定頁中的數據會有序排放并組成一個單向鏈表）。

對于一個普通的二級索引，葉子節點存儲是索引列和主鍵值，非葉子節點頁存儲是下方葉子節點的最小值和對應的頁地址。（葉子節點是有序的，對應的主鍵可不一定）

那么對于兩個區間查詢(-∞，6)和(6，+∞)意味著什么呢？

如果一個二級索引樹的數據簡化為12條數據，那么就有1-5，7-12共計11條數據要被掃描，然后進行11次回表。

也就是說，如果表中有120萬條數據，要回表110萬次。

emm，MySQL一看這么麻煩，還掃描什么二級索引樹啊，直接全表掃描走起吧。

那難道說，對于!=查詢就用不了索引了嗎？

非也。

如果數據集是下面這種，情況可能就不一樣了。

在這個索引樹上，索引值為6的占據了很大一部分，那么MySQL掃描成本就會大大降低了。

此時掃描的行數變成了1，10-12，共計3行。

相對于全表掃描，此時走二級索引樹掃描，顯然代價是比較低的。

也就是說，對于!=是否可以使用索引，要看具體的場景。

總結一下就是，MySQL判斷某個sql是否走索引，其實取決于成本分析。

如果使用二級索引的成本更低，MySQL就會傾向于使用二級索引。

如果使用二級索引掃描的行數占比過高，導致需要頻繁的回表，MySQL經過計算之后覺得走二級索引的代價太大了，就會使用全表掃描。