前言

最近一直忙著處理原來老專案遺留的一些SQL優化問題，由於當初表的設計以及欄位設計的問題，隨著業務的增長，出現了大量的慢SQL，導致MySQL的CPU資源飆升，基於此，給大家簡單分享下這些比較使用的易於學習和使用的經驗。

這次的話簡單說下如何防止你的索引失效。

再說之前我先根據我最近的經驗說下我對索引的看法，我覺得並不是所以的表都需要去建立索引，對於一些業務資料，可能量比較大了，查詢資料已經有了一點壓力，那麼最簡單、快速的辦法就是建立合適的索引，但是有些業務可能表裡就沒多少資料，或者表的使用頻率非常不高的情況下是沒必要必須要去做索引的。就像我們有些表，2年了可能就10來條資料，有索引和沒索引效能方面差不多多少。

索引只是我們優化業務的一種方式，千萬為了為了建索引而去建索引。

下面是我此次測試使用的一張表結構以及一些測試資料

CREATE TABLE `user` (
 `id` int(5) unsigned NOT NULL AUTO_INCREMENT,`create_time` datetime NOT NULL,`name` varchar(5) NOT NULL,`age` tinyint(2) unsigned zerofill NOT NULL,`sex` char(1) NOT NULL,`mobile` char(12) NOT NULL DEFAULT '',`address` char(120) DEFAULT NULL,`height` varchar(10) DEFAULT NULL,PRIMARY KEY (`id`),KEY `idx_createtime` (`create_time`) USING BTREE,KEY `idx_name_age_sex` (`name`,`sex`,`age`) USING BTREE,KEY `idx_ height` (`height`) USING BTREE,KEY `idx_address` (`address`) USING BTREE,KEY `idx_age` (`age`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=261 DEFAULT CHARSET=utf8;

INSERTINTO`bingfeng`.`user`(`id`,`create_time`,`name`,`age`,`mobile`,`address`,`height`)VALUES(1,'2019-09-0210:17:47','冰峰',22,'男','1','陝西省咸陽市彬縣','175');INSERTINTO`bingfeng`.`user`(`id`,`height`)VALUES(2,'2020-09-0210:17:47','松子',13,'女',NULL,'180');INSERTINTO`bingfeng`.`user`(`id`,`height`)VALUES(3,'2020-09-0210:17:48','蠶豆',20,`height`)VALUES(4,'17765010977','陝西省西安市','155');INSERTINTO`bingfeng`.`user`(`id`,`height`)VALUES(255,'竹筍','我測試下可以儲存幾個中文',`height`)VALUES(256,'2020-09-0310:17:47',21,'','167');INSERTINTO`bingfeng`.`user`(`id`,`height`)VALUES(257,'小紅',`height`)VALUES(258,'小鵬','188');INSERTINTO`bingfeng`.`user`(`id`,`height`)VALUES(259,'張三',`height`)VALUES(260,'李四','165');

單個索引

1、使用!= 或者 <> 導致索引失效

SELECT*FROM`user`WHERE`name`!='冰峰';

我們給name欄位建立了索引，但是如果!= 或者 <> 這種都會導致索引失效，進行全表掃描，所以如果資料量大的話，謹慎使用

可以通過分析SQL看到，type型別是ALL，掃描了10行資料，進行了全表掃描。<>也是同樣的結果。

2、型別不一致導致的索引失效

在說這個之前，一定要說一下設計表字段的時候，千萬、一定、必須要保持欄位型別的一致性，啥意思？比如user表的id是int自增，到了使用者的賬戶表user_id這個欄位，一定、必須也是int型別，千萬不要寫成varchar、char什麼的騷操作。

SELECT*FROM`user`WHEREheight=175;

這個SQL諸位一定要看清楚，height表字段型別是varchar，但是我查詢的時候使用了數字型別，因為這個中間存在一個隱式的型別轉換，所以就會導致索引失效，進行全表掃描。

現在明白我為啥說設計欄位的時候一定要保持型別的一致性了不，如果你不保證一致性，一個int一個varchar，在進行多表聯合查詢（eg: 1 = '1'）必然走不了索引。

遇到這樣的表，裡面有幾千萬資料，改又不能改，那種痛可能你們暫時還體會。

少年們，切記，切記。

3、函式導致的索引失效

SELECT*FROM`user`WHEREDATE(create_time)='2020-09-03';

如果你的索引欄位使用了索引，對不起，他是真的不走索引的。

4、運算子導致的索引失效

SELECT*FROM`user`WHEREage-1=20;

如果你對列進行了（+，-，*，/，!）,那麼都將不會走索引。

5、OR引起的索引失效

SELECT*FROM`user`WHERE`name`='張三'ORheight='175';

OR導致索引是在特定情況下的，並不是所有的OR都是使索引失效，如果OR連線的是同一個欄位，那麼索引不會失效，反之索引失效。

6、模糊搜尋導致的索引失效

SELECT*FROM`user`WHERE`name`LIKE'%冰';

這個我相信大家都明白，模糊搜尋如果你字首也進行模糊搜尋，那麼不會走索引。

7、NOT IN、NOT EXISTS導致索引失效

SELECTs.*FROM`user`sWHERENOTEXISTS(SELECT*FROM`user`uWHEREu.name=s.`name`ANDu.`name`='冰峰')

SELECT*FROM`user`WHERE`name`NOTIN('冰峰');

這兩種用法，也將使索引失效。但是NOT IN 還是走索引的，千萬不要誤解為 IN 全部是不走索引的。我之前就有誤解（丟人了...）。

8、IS NULL不走索引，IS NOT NULL走索引

SELECT*FROM`user`WHEREaddressISNULL

不走索引。

SELECT*FROM`user`WHEREaddressISNOTNULL;

走索引。

根據這個情況，建議大家這設計欄位的時候，如果沒有必要的要求必須為NULL，那麼最好給個預設值空字串，這可以解決很多後續的麻煩（有深刻的體驗<體驗=教訓>）。

符合索引

1、最左匹配原則

EXPLAINSELECT*FROM`user`WHEREsex='男';

EXPLAINSELECT*FROM`user`WHEREname='冰峰'ANDsex='男';

測試之前，刪除其他的單列索引。

啥叫最左匹配原則，就是對於符合索引來說，它的一個索引的順序是從左往右依次進行比較的，像第二個查詢語句，name走索引，接下來回去找age，結果條件中沒有age那麼後面的sex也將不走索引。

注意：

SELECT*FROM`user`WHEREsex='男'ANDage=22AND`name`='冰峰';

可能有些搬磚工可能跟我最開始有個誤解，我們的索引順序明明是name、sex、age，你現在的查詢順序是sex、age、name，這肯定不走索引啊，你要是自己沒測試過，也有這種不成熟的想法，那跟我一樣還是太年輕了，它其實跟順序是沒有任何關係的，因為mysql的底層會幫我們做一個優化，它會把你的SQL優化為它認為一個效率最高的樣子進行執行。所以千萬不要有這種誤解。

2、如果使用了!=會導致後面的索引全部失效

SELECT*FROM`user`WHEREsex='男'AND`name`!='冰峰'ANDage=22;

我們在name欄位使用了 != ，由於name欄位是最左邊的一個欄位，根據最左匹配原則，如果name不走索引，後面的欄位也將不走索引。

關於符合索引導致索引失效的情況能說的目前就這兩種，其實我覺得對於符合索引來說，重要的是如何建立高效的索引，千萬不能說我用到那個欄位我就去建立一個單獨的索引，不是就可以全域性用了嘛。這樣是可以，但是這樣並沒有符合索引高效，所以為了成為高階的搬磚工，我們還是要繼續學習，如何建立高效的索引。

總結

到此這篇關於導致MySQL索引失效的一些常見寫法的文章就介紹到這了,更多相關MySQL索引失效的常見寫法內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！