前言
写这篇文章源自一位杠精同事提了个问题,左侧原则跟where条件顺序有无关系?我想了想,好像是有关系的!不敢确定,但是自己又懒得动手测试,于是发起ETC自动抬杠功能,强行杠了一拨,结果杠输了,接下来即是动手验证..
预习执行计划
实践
咱们先申明前置条件,创建表如下:
创建复合索引如下注意哦,索引使用的BTree:
我们先来一个提问,看如下两条sql,我们花5秒时间思考下,会走索引吗?
sql-1 根据code查询:
时间到,咱们看下实际结果.
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) 不走索引.
喜欢的话记得点个赞或者加个关注哟.
