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

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

以此SQL為例：

select * from t where k != 6;

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

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

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

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

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

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

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

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

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

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

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

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

非也。

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

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

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

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

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

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

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

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