Mysql索引失效的底層原理

1.索引失效的原因

創(chuàng)新互聯(lián)主營澄邁網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,成都app軟件開發(fā)公司,澄邁h5小程序定制開發(fā)搭建,澄邁網(wǎng)站營銷推廣歡迎澄邁等地區(qū)企業(yè)咨詢

聯(lián)合索引排序的原理：先對第一個字段進行排序，在第一個字段相同的情況下考慮第二個字段，然后在第二個字段相同的情況下才考慮第三個字段...

CREATE TABLE 'test_user'(

'id' int(11) not null auto_increment comment '主鍵id',

‘user_id’ varchar(36) not null comment '用戶id',

'phone' varchar(20) not null comment '用戶名稱',

'lan_id' int(9) not null comment '本地網(wǎng)',

'region_id' int(9) not null comment '區(qū)域'

)ENGINE=InnoDB Auto_increment=4057960 Default charset=utf8mb4;

假設(shè)將('phone', 'lan_id', 'region_id')組成的聯(lián)合索引

Explain select * from test_user where lan_id = 1;

此時的索引是失效的，因為聯(lián)合索引是遵循最左前綴法則即第一個字段有序的情況下lan_id才有序?，F(xiàn)在是跳過phone,直接搜索lan_id相當于在一個無序的B+樹上搜索，所以只能全表掃描。

例1下例范圍查找的右邊索引會失效

Explain select * from test_user where a 1 and b = 1;

為什么索引會失效？

因為我們可以找到a 1的所有的節(jié)點，但是此時的b索引是無序的，仍然不可以通過二分查找法來查找

例2. like查詢中，如果%放在兩邊或者放到左邊，它都是不走索引的。只有%放到右邊，它某些情況才會走這個索引。這是什么原因？

字符串在B+樹里面存儲的時候，它也是按照字母的大小去排序。首先按照第一個字母去比較，如果第一個字母相同則按照第二個字母去比較和最佳左前綴法則相似。如果左邊用了%，那后面的字符是無序的，此時就不能使用二分查找來定位元素還是退化為了全表掃描。

3.Mysql中的索引查詢?yōu)槭裁词褂昧薆+樹結(jié)構(gòu)，而不使用哈希索引或者B樹？

首先哈希值是無序的，不能夠進行范圍查找。

平衡二叉樹的缺點是當數(shù)據(jù)量非常大的時候，其深度也會非常深這樣也會導(dǎo)致查找效率慢。其次其存在回旋查找的問題。比如說當存在范圍查詢5的時候定位到該元素之后還得回溯到前面的節(jié)點元素6，7

B樹的最大特點是一個節(jié)點可以存儲多個值，這樣可以使得樹的高度變矮，從而使得樹的查找速度變快。但是其也存在回旋查找的問題。

B+樹則解決了這個問題，它的非葉子節(jié)點存儲的是key,其葉子節(jié)點既存儲了key也存儲了value并且其葉子節(jié)點是有序的，節(jié)點之間用指針相連也正是因為這一點使得B+樹在范圍查詢的時候不存在回旋問題。

mysql 避免索引失效

where條件==order by 條件==group by 條件 按順序遵守 最佳左前綴法則

假設(shè)創(chuàng)建了復(fù)合索引：a,b,c

不在索引列上做任何的操作（計算、函數(shù)、顯式或隱式的類型轉(zhuǎn)換），否則會導(dǎo)致索引失效而轉(zhuǎn)向全表掃描

1、字符不加單引號會導(dǎo)致索引失效

name字段為varchar類型

這條sql發(fā)生了隱式的類型轉(zhuǎn)換：數(shù)值==字符串。所以導(dǎo)致了全表掃描，索引失效

應(yīng)盡量避免在 where 子句中對字段進行表達式操作，這將導(dǎo)致引擎放棄使用索引而進行全表掃描。如：

mysql中的范圍條件有：in/not in、 like、 、BETWEEN AND ；

后面的索引失效

in會導(dǎo)致索引全部失效?。?！

BETWEEN AND 范圍條件不會導(dǎo)致索引失效?。?！

盡量讓索引列和查詢列一致；減少select * 的使用

1、查詢表結(jié)構(gòu)

2、查詢表的索引結(jié)構(gòu)

聯(lián)合索引：name,age,post；說明add_time字段沒有添加索引

3、查看select * 的執(zhí)行計劃

4、查看 select name,age,pos的執(zhí)行計劃

5、如果select只用一部分索引

like以通配符開頭（’%abc…’）mysql索引失效會變成全表掃描的操作。

解決：可以使用 覆蓋索引 來解決這個問題！

1、先查看表上的索引

id、name、age、pos 四個字段上都有索引； 注意：name是聯(lián)合索引中的第一個，帶頭大哥！

2、查看表結(jié)構(gòu)

有個add_time字段沒有用到索引

3、查看執(zhí)行計劃

使用UNION ALL

假設(shè)創(chuàng)建了聯(lián)合索引 x(a,b,c)

ps：like雖然也是范圍查詢但是區(qū)別于、，%用在最前面就只用到索引a了；%用在最后面可以用到a+b+c！

下面的sql幾乎違背了上面的所有原則，索引依然全部生效。因為select是索引覆蓋的，select里不包含沒有建立索引的字段。因此總是用到索引的?？梢钥闯鰜硭饕采w在sql優(yōu)化中的作用性

mysql 索引失效總結(jié)

首先我們還是先把表結(jié)構(gòu)說下：用戶表tb_user結(jié)構(gòu)如下：

1、 不要在索引列上進行運算操作， 索引將失效。

手機號phone字段有唯一索引，當根據(jù)phone字段進行函數(shù)運算操作之后，索引失效:

2、 字符串類型字段使用時，不加引號，索引將失效。

如果字符串不加單引號，對于查詢結(jié)果，沒什么影響，但是數(shù) 據(jù)庫存在隱式類型轉(zhuǎn)換，索引將失效。

3、 如果僅僅是尾部模糊匹配，索引不會失效。如果是頭部模糊匹配，索引失效。

接下來，我們來看一下這三條SQL語句的執(zhí)行效果，查看一下其執(zhí)行計劃：

由于下面查詢語句中，都是根據(jù)profession（專業(yè)）字段查詢，profession字段是一個普通的索引， 我們主要看一下，模糊查詢時，%加在關(guān)鍵字之前，和加在關(guān)鍵字之后的影響。

經(jīng)過上述的測試，我們發(fā)現(xiàn)，在like模糊查詢中，在關(guān)鍵字后面加%，索引可以生效。而如果在關(guān)鍵字 前面加了%，索引將會失效。

4、 用or分割開的條件， 如果or前的條件中的列有索引，而后面的列中沒有索引，那么涉及的索引都不會 被用到。

由于age沒有索引，所以即使id有索引，索引也會失效。所以需要針對于age也要建立索引。

5、 數(shù)據(jù)分布影響：如果MySQL評估使用索引比全表更慢，則不使用索引。