Mysql的In关键字的使用

最新推荐文章于 2025-06-18 21:56:33 发布

javashareauthor

最新推荐文章于 2025-06-18 21:56:33 发布

阅读量8.6k

点赞数 2

CC 4.0 BY-SA版权

分类专栏： Mysql 文章标签： mysql

本文链接：https://blog.youkuaiyun.com/javashareauthor/article/details/91042969

Mysql 专栏收录该内容

11 篇文章

订阅专栏

本文通过实验探讨了MySQL中IN关键字对索引的影响。发现对于主键和带有索引的字段，IN操作符可以有效利用索引，但在某些特定情况下，如子查询和数据量较小的表中，可能会导致索引不被使用。进一步研究了不同场景下IN操作符的索引使用情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在一次的工作之余，几个同事一起聊到了mysql中In关键词的使用。当时根据我的记忆，脱口而出：in最好少用，会导致查询的字段不走索引，效率很低。但是其中一个同事回：并不是都不走索引的。我这个时候愣住了，难道我最初接受的这个信息有误？不行，我一定要亲自动手操作一番，于是我做了如下的事情。

我先写了以下的sql语句：

EXPLAIN select * from user where id in ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15') ;

其中id是主键。

执行后的结果如下：

解释：

Id:是代表的执行顺序，id越大代表执行的优先级越高。

Select_type:simple代表简单的select查询，查询中不包含子查询或者UNION。

Table:是查询的表名称。

Type:type所显示的是查询使用了哪种类型.从最好到最差依次是：

system > const > eq_ref > ref > range > index > all

system 表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计

const 表示通过索引一次就找到了，const用于比较primary key 或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量。

首先进行子查询得到一个结果的d1临时表，子查询条件为id = 1 是常量，所以type是const，id为1的相当于只查询一条记录，所以type为system。

eq_ref 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描

ref 非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。

range 只检索给定范围的行，使用一个索引来选择行，key列显示使用了哪个索引，一般就是在你的where语句中出现between、< 、>、in等的查询，这种范围扫描索引比全表扫描要好，因为它只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引。

index Full Index Scan，Index与All区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。（也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘读取的）

Possible_keys:代表显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用。

Key:实际使用的索引，如果为NULL，则没有使用索引;

Key_len:表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，在不损失精确性的情况下，长度越短越好.

Ref:显示索引的那一列被使用了，如果可能的话，最好是一个常数.

Rows:根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数.

Extra:包含不适合在其他列中显式但十分重要的额外信息.

分析：可知上述的查询是使用了主键的范围扫描，索引是生效了的。

由于上述是使用的主键作为查询条件，太过特殊。于是我找了一个也是使用了索引的字段进行查询。

案例如下：

EXPLAIN select * from user where  nickname  in ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15' )

执行结果如下：

可知：上述的查询也是使用了索引的范围扫描，索引是生效的。

接着看一下带有子查询的案例：

EXPLAIN select * from user where  nickname  in (select nickname from user where nickname='1' or nickname='2' )

执行结果如下：

可知：上述的查询也是使用了索引的范围扫描，索引是生效的。

于是我新建一张表，把id和nickname放入到这张表，但是数据只有10条，然后进行如下查询：

EXPLAIN select * from user where  nickname  in (select nickname from temptest)

执行的结果如下：

可知：在查询user表的nickname任然使用了索引。

但是换一个sql语句

EXPLAIN select * from waiter where userid in (select id from user where createtime >'2019-01-01')

执行的结果：

可知：waiter表不走索引了。原因未知，没有研究清楚。有谁清楚mysql中in机制的麻烦一起分享一下。