百度360必应搜狗淘宝本站头条
当前位置:网站首页 > 技术文章 > 正文

MySQL 的IN查询详解(mysql in查询语句)

nanshan 2024-10-13 03:52 15 浏览 0 评论

1、IN()查询返回布尔值

如果IN()左侧表达式等于IN()列表中的任何值,则返回1(true),否则返回0(false)。

以下查询返回0:

SELECT 2 IN (0,3,5,7);

以下查询返回1

SELECT 'wefwf' IN ('wee','wefwf','weg');

执行过程:先对IN()列表中的值进行排序,然后使用二分查找法(binary search)搜索匹配的值,速度很快。


2、IN()可用于比较行构造器

行构造器允许同时比较多个值。例如,这三个语句在语义上是等价的:

SELECT * FROM t1 WHERE (column1,column2) = (1,1);
SELECT * FROM t1 WHERE (column1,column2) IN (1,1);
SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;

以下查询返回1:

SELECT (3,4) IN ((1,2), (3,4));

以下查询返回0:

SELECT (3,4) IN ((1,2), (3,5));


3、IN()列表中的值应是同类型

千万不要在IN()列表中混用带引号的值和未带引号的数值,因为带引号的(如字符串)和未带括号的(如数字)值的比较规则不同,混合类型可能导致意外的结果。

错误用法:

SELECT val1 FROM tbl1 WHERE val1 IN (1,2,'a');

正确用法:

SELECT val1 FROM tbl1 WHERE val1 IN ('1','2','a');

在以下两种比较运算中,比较值都转换为浮点值0.0,比较结果都为1(或true)。是不是有点意外?

SELECT 'a' IN (0), 0 IN ('b');


4、IN()列表中值的数量

IN()列表中的值数量仅受max_allowed_packet值的限制。也就是说,一般情况下,我们不需要考虑IN()值列表中的数量会超过限制。

max_allowed_packet是一个系统变量,表示MySQL服务端或者客户端接收通信数据包的最大大小,MySQL服务端和客户端都有这个限制。

MySQL 8服务端或客户端的最大数据包是1GB。最大允许数据包的协议限制为1GB。该值应该是1024的倍数;非倍数被四舍五入到最接近的倍数。

什么是通信数据包?比如下面这些:

  • 一个SQL是一个数据包。
  • 返回查询结果时,一行数据算一个数据包。
  • 解析的binlog ,如果用MySQL客户端导入,一个SQL算一个数据包。
  • 在复制中,一个event算一个数据包。


5、返回NULL的情况

IN()查询在以下两种情况下返回NULL:

  • 左侧的表达式为NULL
  • IN()值列表中未找到匹配项并且列表中的一项为NULL

例如两个查询,都返回NULL:

//结果返回NULL
SELECT null IN (0,null,5,7);

//结果返回NULL
SELECT 3 IN (0,null,5,7);


6、IN()查询实验

创建以下数据库表:

CREATE TABLE `sys_user` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键',
  `user_code` varchar(10) NOT NULL COMMENT '编号',
  `user_name` varchar(20) NOT NULL COMMENT '姓名',
  `age` tinyint UNSIGN NOT NULL COMMENT '年龄',
  `score` tinyint UNSIGN NOT NULL COMMENT '积分',
  `create_date` datetime NOT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

首先存入这些测试数据:

实验一:隐式类型转换影响查询效率

对user_code列建唯一索引:

ALTER TABLE `sys_user` ADD UNIQUE INDEX `idx_unique_code` (`user_code` ASC);

表中的user_code列为VARCHAR类型,IN()查询时值列表中的每个值应该用单引号括起来,例如,对比下面两个SQL语句:

//user_code为字符串类型,以下查询不需要类型转换
select * from sys_user where user_code in('1001','1002','1003');

//以下查询需要进行隐性类型转换
select * from sys_user where user_code in(1001,1002,1003);

分别用explain分析查询计划:

//step 1
explain select * from sys_user where user_code in('1001','1002','1003');

//step 1输出
//----------------------------------------
           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:range	
possible_keys:idx_unique_code
          key:idx_unique_code	
      key_len:42
          ref:NULL
         rows:3
     filtered:100.00
        Extra:Using index condition
        
//step 2
explain select * from sys_user where user_code in(1001,1002,1003);

//step 2输出
//----------------------------------------
           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:ALL	
possible_keys:idx_unique_code
          key:NULL	
      key_len:NULL
          ref:NULL
         rows:5
     filtered:50.00
        Extra:Using where

实验结果

以上两个SQL语句虽然查询结果相同,但通过explain分析可以看出,如果让MySQL进行隐性类型转换,查询将变为全表扫描,效率低下。

实验二:比较的值的数量影响查询效率

仍然使用唯一索引idx_unique_code,IN()值列表的值数量大于等于表中全部记录数,例如:

//IN()值个数等于表数据总行数
explain select * from sys_user where user_code in('1001','1002','1003','1004','1005');

//IN()值个数大于表数据总行数
explain select * from sys_user where user_code in('1001','1002','1003','1004','1005','1006');

二者均输出如下:
           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:ALL		
possible_keys:idx_unique_code
          key:NULL	
      key_len:NULL
          ref:NULL
         rows:5
     filtered:100.00
        Extra:Using where

实验结果

当IN()值列表的数量大于等于表中全部记录数时,唯一索引idx_unique_code未被使用,而是执行全表扫描。

实验三:IN()参数太多导致索引失效

给sys_user表插入测试数据,总记录数达到500条。在IN()值数量小于等于88时,索引生效:

//IN()值数量小于等于88时,索引生效
explain select * from sys_user where user_code in('1001','1002','1003','1004','1005','1006','1007','1008','1009','1010','1011','1012','1013','1014','1015','1016','1017','1018','1019','1020','1021','1022','1023','1024','1025','1026','1027','1028','1029','1030','1031','1032','1033','1034','1035','1036','1037','1038','1039','1040','1041','1042','1043','1044','1045','1046','1047','1048','1049','1050','1051','1052','1053','1054','1055','1056','1057','1058','1059','1060','1061','1062','1063','1064','1065','1066','1067','1068','1069','1070','1071','1072','1073','1074','1075','1076','1077','1078','1079','1080','1081','1082','1083','1084','1085','1086','1087','1088');

//explain输出
           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:range	
possible_keys:idx_code
          key:idx_code	
      key_len:42
          ref:NULL
         rows:88
     filtered:100.00
        Extra:Using index comdition

而当IN()值列表的数量大于88时,索引失效,查询执行全表扫描:

           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:ALL	
possible_keys:idx_code
          key:NULL	
      key_len:NULL
          ref:NULL
         rows:500
     filtered:17.80
        Extra:Using where

当把上面的查询语句加上LIMIT关键字,LIMIT关键字后的数量小于表记录总数(500)时,索引又生效了。

实验结果

在IN()查询中的参数个数需要进行控制,以避免索引失效的风险。比如约定50为上限,把这个限制加入编码规范进行约束。另一种简单的处理办法是,只要是IN()查询,就加上LIMIT关键字限制。

实验四:Index dive问题(索引潜水)

当IN()查询所比较的列上的索引为非唯一索引,在执行查询时,MySQL优化器会使用index dive(索引潜水)或index statistics(索引统计)的方法来估算结果行数,进而选择相应的查询计划。

Index dive方式得到的预估值是比较准确的。但随着IN()表达式中比较值数量的增加,MySQL优化器生成行估计所需的时间会变长,比较值的数量超过临界值后,会使用Index statistics的方法估算结果行数。Index statistics估算的误差较大,其特点是对数量大的值列表进行快速的行估计

这个临界值就是MySQL系统变量eq_range_index_dive_limit,MySQL8中,该变量的默认值为200。通过如下命令查看:

show variables like 'eq_range_index_dive_limit';

继续通过实验来查看:

先对user_code列建立普通索引:

ALTER TABLE `sys_user` ADD INDEX `idx_code` (`user_code` ASC);
//IN()中的值控制在199个
explain select * from sys_user where user_code in('1001','1002','1003','1004','1005','1006','1007','1008','1009','1010','1011','1012','1013','1014','1015','1016','1017','1018','1019','1020','1021','1022','1023','1024','1025','1026','1027','1028','1029','1030','1031','1032','1033','1034','1035','1036','1037','1038','1039','1040','1041','1042','1043','1044','1045','1046','1047','1048','1049','1050','1051','1052','1053','1054','1055','1056','1057','1058','1059','1060','1061','1062','1063','1064','1065','1066','1067','1068','1069','1070','1071','1072','1073','1074','1075','1076','1077','1078','1079','1080','1081','1082','1083','1084','1085','1086','1087','1088','1089','1090','1091','1092','1093','1094','1095','1096','1097','1098','1099','1100','1101','1102','1103','1104','1105','1106','1107','1108','1109','1110','1111','1112','1113','1114','1115','1116','1117','1118','1119','1120','1121','1122','1123','1124','1125','1126','1127','1128','1129','1130','1131','1132','1133','1134','1135','1136','1137','1138','1139','1140','1141','1142','1143','1144','1145','1146','1147','1148','1149','1150','1151','1152','1153','1154','1155','1156','1157','1158','1159','1160','1161','1162','1163','1164','1165','1166','1167','1168','1169','1170','1171','1172','1173','1174','1175','1176','1177','1178','1179','1180','1181','1182','1183','1184','1185','1186','1187','1188','1189','1190','1191','1192','1193','1194','1195','1196','1197','1198','1199');

//explain输出
           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:ALL	
possible_keys:idx_code
          key:NULL	
      key_len:NULL
          ref:NULL
         rows:500
     filtered:39.80
        Extra:Using where

再将IN()中参数增加到200,执行explain输出如下:

           id:1	
  select_type:SIMPLE	
        table:sys_user
   partitions:NULL
         type:ALL	
possible_keys:idx_code
          key:NULL	
      key_len:NULL
          ref:NULL
         rows:500
     filtered:40.00
        Extra:Using where

再分别对199个参数和200个参数的SQL语句执行查询,查看OPTIMIZER_TRACE表中各自的TRACE信息,在rows_estimation内容块中,index_dives_for_eq_ranges的值分别为true和false,即表明IN()参数个数为199时,使用了index dive方式,IN()参数大于等于200时未使用index dive方式。

OPTIMIZER_TRACE表位于information_schema数据库,提供优化器跟踪功能,为被跟踪语句生成的信息。该功能默认关闭,通过以下命令启用:

set optimizer_trace="enabled=on";


启用后,执行目标SQL语句,然后执行以下查询获取跟踪信息:

select * from information_schema.OPTIMIZER_TRACE;

最后,主要关注查询结果中的TRACE列信息。

实验结果

  • explain分析结果显示预估行数都是500,index dive方式预估行数并没有很准确(实际应是199)。可能与实验数据有关,未进一步分析。
  • IN()查询使用Index dive方式的默认临界值是200,当值个数小于200时,使用Index dive方式,当值个数大于等于200时,使用Index statistics方式。

Index dive方式适用于数据量小的表,且IN()查询参数值较少的情况。反之应使用Index statistics方式以提升查询速度。

在实际运用中,可以对eq_range_index_dive_limit默认值进行调整,如果希望在对N个值做IN()查询时使用index dive方式,可将eq_range_index_dive_limit设置为N+1。若希望始终使用Index dive方式,可将eq_range_index_dive_limit设置为0。

相关推荐

雷军1994年写的老代码曝光,被称像诗一样优雅

大数据文摘授权转载自程序员的那些事雷军的代码像诗一样优雅↓↓↓有些网友在评论中质疑,说雷军代码不会是“屎”一样优雅吧。说这话的网友,也许是开玩笑的,也许是真没看过雷军写过的代码。在2011年的时候,我...

原创经验分享:低级bug耗费12小时Fix

调试某程序非常简单的程序,简单到认为不可能存在缺陷,但该BUG处理时间超过12小时:程序属于后台进程,监控系统每隔15秒检查外设IO状态,IO异常后发出报警或复位外设,外设都在linux下有/sys/...

SpringBoot实现的简单停车位管理系统附带导入和演示教程视频

这一次为大家带来的是简单的停车位管理系统,基于SpringBoot+Thymeleaf+Mybatis框架,这个系统相对来说比较简单,很容易学习并快速上手,因为逻辑很清晰,没有太复杂的代码逻辑,所以学...

一个开箱即用的代码生成器(代码自动生成工具开源)

今天给大家推荐一个好用的代码生成器,名为renren-generator,该项目附带前端页面,可以很方便的选择我们所需要生成代码的表。首先我们通过git工具克隆下来代码(地址见文末),导入idea。...

【免费开源】JeecgBoot单点登录源码全部开源了

JeecgBoot单点登录源码全部开源了,有需要的朋友可以来薅羊毛了。一、JeecgBoot介绍JeecgBoot是一款企业级的低代码平台!前后端分离架构SpringBoot2.x,SpringCl...

SpringBoot+JWT+Shiro+Mybatis实现Restful快速开发后端脚手架

作者:lywJee来源:cnblogs.com/lywJ/p/11252064.html一、背景前后端分离已经成为互联网项目开发标准,它会为以后的大型分布式架构打下基础。SpringBoot使编码配置...

为什么越来越多的人选择使用idea软件

IDEA软件是什么?IDEA软件是干什么的?为什么越来越多的人选择使用IDEA软件?IDEA软件,全称IntelliJIDEA,它是由JetBrains公司开发开发的一款功能强大的集成开发环境(ID...

开题报告大学生互助系统(附源码)java毕设

本系统(程序+源码)带文档lw万字以上文末可获取一份本项目的java源码和数据库参考。系统程序文件列表开题报告内容选题背景随着互联网技术的飞速发展,大学生群体对信息共享与互助的需求日益增长。关于大...

SpringBoot项目快速开发框架JeecgBoot——项目简介及系统架构!

项目简介及系统架构JeecgBoot是一款基于SpringBoot的开发平台,它采用前后端分离架构,集成的框架有SpringBoot2.x、SpringCloud、AntDesignof...

新手配电脑13代CPU怎么选择(新手配电脑13代cpu怎么选择好)

Intel第13代酷睿i3、i5、i7、i9系列处理器的核心参数、性能差异及适用群体的详细说明(以桌面端为例):一、13代酷睿全系参数对比(桌面端主流型号)参数i3-13100i5-13600Ki7-...

加速 SpringBoot 应用开发,官方热部署神器真带劲

平时使用SpringBoot开发应用时,修改代码后需要重新启动才能生效。如果你的应用足够大的话,启动可能需要好几分钟。有没有什么办法可以加速启动过程,让我们开发应用代码更高效呢?今天给大家推荐一款Sp...

基于微信小程序的移动端物流系统-计算机毕业设计源码+LW文档

摘要随着Internet的发展,人们的日常生活已经离不开网络。未来人们的生活与工作将变得越来越数字化,网络化和电子化。网上管理,它将是直接管理移动端物流系统app的最新形式。本论文是以构建移动端物流系...

springboot教务管理系统+微信小程序云开发附带源码

今天给大家分享的程序是基于springboot的管理,前端是小程序,系统非常的nice,不管是学习还是毕设都非常的靠谱。本系统主要分为pc端后台管理和微信小程序端,pc端有三个角色:管理员、学生、教师...

SpringBoot全家桶:23篇博客加23个可运行项目让你对它了如指掌

SpringBoot现在已经成为Java开发领域的一颗璀璨明珠,它本身是包容万象的,可以跟各种技术集成。本项目对目前Web开发中常用的各个技术,通过和SpringBoot的集成,并且对各种技术通...

Maven+JSP+Servlet+C3P0+Mysql实现的音乐库管理系统

本系统基于Maven+JSP+Servlet+C3P0+Mysql实现的音乐库管理系统。简单实现了充值、购买歌曲、poi数据导入导出、歌曲上传下载、歌曲播放、用户注册登录注销等功能。难度等级:简单技术...

取消回复欢迎 发表评论: