MySQL中使用IN会不会走索引分析

及时获取有趣有料的技术文章

MySQL中使用IN会不会走索引

文章很短,先看下结论,在看下文。

结论:IN肯定会走索引,但是当IN的取值范围较大时会导致索引失效,走全表扫描

navicat可视化工具使用explain函数查看sql执行信息

场景1:当IN中的取值只有一个主键时

我们只需要注意一个最重要的type的信息很明显的提现是否用到索引:

type结果值从好到坏依次是:

systemconsteq_refreffulltextref_or_nullindex_mergeunique_subqueryindex_subqueryrangeindexALL

all:全表扫描

index:另一种形式的全表扫描,只不过他的扫描方式是按照索引的顺序

range:有范围的索引扫描,相对于index的全表扫描,他有范围限制,因此要优于index

ref:查找条件列使用了索引而且不为主键和unique。其实,意思就是虽然使用了索引,但该索引列的值并不唯一,有重复。这样即使使用索引快速查找到了第一条数据,仍然不能停止,要进行目标值附近的小范围扫描。但它的好处是它并不需要扫全表,因为索引是有序的,即便有重复值,也是在一个非常小的范围内扫描。

const:通常情况下,如果将一个主键放置到where后面作为条件查询,mysql优化器就能把这次查询优化转化为一个常量。至于如何转化以及何时转化,这个取决于优化器

一般来说,得保证查询至少达到range级别,最好能达到ref,type出现index和all时,表示走的是全表扫描没有走索引,效率低下,这时需要对sql进行调优。

当extra出现Usingfilesor或Usingtemproary时,表示无法使用索引,必须尽快做优化。

possible_keys:sql所用到的索引

key:显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL

rows:显示MySQL认为它执行查询时必须检查的行数。

这里可以参考之前写的一篇:用MySQL执行计划分析DATE_FORMAT函数对索引的影响

场景2:扩大IN中的取值范围

此时仍然走了索引,但是效率降低了

场景3:继续扩大IN的取值范围

看上面的图,发现此时已经没有走索引了,而是全表扫描。

在说一下结论

结论:IN肯定会走索引,但是当IN的取值范围较大时会导致索引失效,走全表扫描。

Bytheway:如果使用了notin,则不走索引。

上面就是本次文章的全部内容,感谢你的阅读,希望对你有帮助,也欢迎你点赞留言和转发~

Seeyounextgoodday~

原文


转载请注明:http://www.aierlanlan.com/cyrz/2485.html