于是试了一下,发现果然如此。
这里的type项是index_merge。搜索后发现是MySQL5.0后的新技术,索引合并。index merge 技术简单说就是在用OR,AND连接的多个查询条件时,可以分别使用前后查询中的索引,然后将它们各自的结果合并交集或并集。当然具体是否使用index merge,优化器会自己选择,比如and连接时有联合索引,或干脆全表查询就很快,就没必要使用它了。
具体可以查阅文档: https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html
还是很有意思的。
可能因为mysql这个东西太复杂,感觉sql优化都快成玄学了。网上流传了很多“奇技淫巧”,让人真假难辨。我觉得可能是过去mysql优化不是很好时,大家有一些优化的技巧,但随着mysql更新优化,现在已经成为过时甚至错误的做法。但这些说法还在流传,造成了我这样的新手的困惑。
所以看来小白要学技术,还是要踏实点多看官方文档,多亲自实践,少看博客,少道听途说。
原因有如下:
1、最佳左前缀原则——如果索引了多列,要遵守最左前缀原则。指的是查询要从索引的最左前列开始并且不跳过索引中的列。
2、不在索引列上做任何 *** 作,会导致索引失效而导致全表扫描。
3、存储引擎不能使用索引中范围条件右边的列,范围之后索引失效。这写条件判断最后放到后面,先定位到小的范围再开始。
4、mysql使用不等于(!= 或者<>)的时候,无法使用索引,会导致索引失效。
5、mysql中使用is not null 或者 is null会导致无法使用索引。
6、mysql中like查询是以%开头,索引会失效变成全表扫描,覆盖索引。
7、mysql中,如果条件中有or,即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)。要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引。
8、如果mysql使用全表扫描要比使用索引快,则不会使用到索引。
注意事项
1、索引列有函数处理或隐式转换,不走索引。
2、索引列倾斜,个别值查询时,走索引代价比走全表扫描高,所以不走索引。
3、索引列没有限制 not null,索引不存储空值,如果不限制索引列是not null,oracle会认为索引列有可能存在空值,所以不会按照索引计算。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)