vlambda博客
学习文章列表

前言

写这篇文章源自一位杠精同事提了个问题,左侧原则跟where条件顺序有无关系?我想了想,好像是有关系的!不敢确定,但是自己又懒得动手测试,于是发起ETC自动抬杠功能,强行杠了一拨,结果杠输了,接下来即是动手验证..

预习执行计划

实践

咱们先申明前置条件,创建表如下:

创建复合索引如下注意哦,索引使用的BTree:

我们先来一个提问,看如下两条sql,我们花5秒时间思考下,会走索引吗?

• sql-1 根据code查询:

• sql-2 根据name查询:

• 5

•   4
  

•           3
  

•                   2
  

•                            1
  

时间到,咱们看下实际结果.

• sql-1 执行计划:

• sql-2 执行计划:

怎麽~样,是否跟你们想象的一样呢?我们继续验证查询条件的顺序是否影响sql的执行计划.   为了方便截图,以下我主要使用SecureCRT查询.

我们列举以上五条sql来验证,查询结果如下:

从上图很明显可以看出,where条件的顺序完全不影响索引的执行,但是很明显上面5条sql所有查询条件都是包含在复合索引内,那要是有查询条件不在符合索引内又是什么结果呢,我们列举4条sql继续求证...

这里发现不一样了,我们的复合索引顺序是name,code,createTime.

当出现非索引字段的查询条件时,只有包含了name的查询条件走了索引.这是为什么呢?

原来是因为我们用了B+树索引数据结构,它是按照从左到右的顺序建立索引,同时mysql查询优化器会优化sql语句,不管where条件顺序如何变化,都会按照索引左侧原则去优化(注意咯是按照索引的左侧,不是where条件的左侧条件哦),以效率最高的方式去执行sql.

好了,到了这里,问题已经解决.不知道童鞋们有没有疑问,上面我们一直说的是BTree索引数据结构,假如是hash结构呢?结果又会是怎样?哈哈哈,不用猜啦,我全部都试过一遍,结果与上面完全一致!

似乎我的分享也该结束了!不,我要加班!哦不对!我热爱学习,热爱加班!继续整理干货!

总结

对于复合索引 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 会走索引.

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

喜欢的话记得点个赞或者加个关注