mysql索引左側(cè)原則,你真的了解嗎?

前言

寫這篇文章源自一位杠精同事提了個(gè)問題,左側(cè)原則跟where條件順序有無關(guān)系?我想了想,好像是有關(guān)系的!不敢確定,但是自己又懶得動(dòng)手測(cè)試,于是發(fā)起ETC自動(dòng)抬杠功能,強(qiáng)行杠了一撥,結(jié)果杠輸了,接下來即是動(dòng)手驗(yàn)證..

預(yù)習(xí)執(zhí)行計(jì)劃

實(shí)踐

咱們先申明前置條件,創(chuàng)建表如下:

創(chuàng)建復(fù)合索引如下注意哦,索引使用的BTree:

我們先來一個(gè)提問,看如下兩條sql,我們花5秒時(shí)間思考下,會(huì)走索引嗎?

• sql-1 根據(jù)code查詢:

• sql-2 根據(jù)name查詢:

• 5

•   4
  

•           3
  

•                   2
  

•                            1
  

時(shí)間到,咱們看下實(shí)際結(jié)果.

• sql-1 執(zhí)行計(jì)劃:

• sql-2 執(zhí)行計(jì)劃:

怎麼~樣,是否跟你們想象的一樣呢?我們繼續(xù)驗(yàn)證查詢條件的順序是否影響sql的執(zhí)行計(jì)劃. ? 為了方便截圖,以下我主要使用SecureCRT查詢.

我們列舉以上五條sql來驗(yàn)證,查詢結(jié)果如下:

從上圖很明顯可以看出,where條件的順序完全不影響索引的執(zhí)行,但是很明顯上面5條sql所有查詢條件都是包含在復(fù)合索引內(nèi),那要是有查詢條件不在符合索引內(nèi)又是什么結(jié)果呢,我們列舉4條sql繼續(xù)求證...

這里發(fā)現(xiàn)不一樣了,我們的復(fù)合索引順序是name,code,createTime.

當(dāng)出現(xiàn)非索引字段的查詢條件時(shí),只有包含了name的查詢條件走了索引.這是為什么呢?

原來是因?yàn)槲覀冇昧薆+樹索引數(shù)據(jù)結(jié)構(gòu),它是按照從左到右的順序建立索引,同時(shí)mysql查詢優(yōu)化器會(huì)優(yōu)化sql語句,不管where條件順序如何變化,都會(huì)按照索引左側(cè)原則去優(yōu)化(注意咯是按照索引的左側(cè),不是where條件的左側(cè)條件哦),以效率最高的方式去執(zhí)行sql.

好了,到了這里,問題已經(jīng)解決.不知道童鞋們有沒有疑問,上面我們一直說的是BTree索引數(shù)據(jù)結(jié)構(gòu),假如是hash結(jié)構(gòu)呢?結(jié)果又會(huì)是怎樣?哈哈哈,不用猜啦,我全部都試過一遍,結(jié)果與上面完全一致!

似乎我的分享也該結(jié)束了!不,我要加班!哦不對(duì)!我熱愛學(xué)習(xí),熱愛加班!繼續(xù)整理干貨!

總結(jié)

對(duì)于復(fù)合索引 idx_A_B_C

有A、A and B、B and A、C and A、A and C、A and B and C、B and A and C、C and B and A 會(huì)走索引.

注意: or 不走索引 C and B or A 或者 A and B or C ?或者 A and (B or C) 不走索引.

喜歡的話記得點(diǎn)個(gè)贊或者加個(gè)關(guān)注