背景介绍

最近在写SQL语句时,对选择IN 还是Exists 犹豫不决,于是把两种方法的SQL都写出来对比一下执行效率,发现IN的查询效率比Exists高了很多,于是想当然的认为IN的效率比Exists好,但本着寻根究底的原则,我想知道这个结论是否适用所有场景,以及为什么会出现这个结果。

网上查了一下相关资料,大体可以归纳为:外部表小,内部表大时,适用Exists;外部表大,内部表小时,适用IN。那我就困惑了,因为我的SQL语句里面,外表只有1W级别的数据,内表有30W级别的数据,按网上的说法应该是Exists的效率会比IN高的,但我的结果刚好相反!!

“没有调查就没有发言权”!于是我开始研究IN 和Exists的实际执行过程,从实践的角度出发,在根本上去寻找原因,于是有了这篇博文分享。

实验数据

我的实验数据包括两张表:t_author表 和 t_poetry表。

对应表的数据量:

t_author表,13355条记录;

t_poetry表,289917条记录。

对应的表结构如下:

CREATE TABLE t_poetry (

id bigint(20) NOT NULL AUTO_INCREMENT,

poetry_id bigint(20) NOT NULL COMMENT '诗词id',

poetry_name varchar(200) NOT NULL COMMENT '诗词名称',

<font color=red> author_id bigint(20) NOT NULL COMMENT '作者id'</font>

PRIMARY KEY (id),

<font color=red>

UNIQUE KEY pid_idx (poetry_id) USING BTREE,

KEY aid_idx (author_id) USING BTREE</font>

) ENGINE=InnoDB AUTO_INCREMENT=291270 DEFAULT CHARSET=utf8mb4

CREATE TABLE t_author (

id int(15) NOT NULL AUTO_INCREMENT,

<font color=red> author_id bigint(20) NOT NULL,</font>

author_name varchar(32) NOT NULL,

dynasty varchar(16) NOT NULL,

poetry_num int(8) NOT NULL DEFAULT '0'

PRIMARY KEY (id),

<font color=red>UNIQUE KEY authorid_idx (author_id) USING BTREE</font>

) ENGINE=InnoDB AUTO_INCREMENT=13339 DEFAULT CHARSET=utf8mb4

执行计划分析

IN 执行过程

sql示例:select * from tabA where tabA.x in (select x from tabB where y>0 );

其执行计划:

(1)执行tabB表的子查询,得到结果集B,可以使用到tabB表的索引y;

(2)执行tabA表的查询,查询条件是tabA.x在结果集B里面,可以使用到tabA表的索引x。

Exists执行过程

sql示例:select from tabA where exists (select from tabB where y>0);

其执行计划:

(1)先将tabA表所有记录取到。

(2)逐行针对tabA表的记录,去关联tabB表,判断tabB表的子查询是否有返回数据,5.5之后的版本使用Block Nested Loop(Block 嵌套循环)。

(3)如果子查询有返回数据,则将tabA当前记录返回到结果集。

tabA相当于取全表数据遍历,tabB可以使用到索引。

实验过程

实验针对相同结果集的IN和Exists 的SQL语句进行分析。

包含IN的SQL语句:

select from t_author ta where author_id in

(select author_id from t_poetry tp where tp.poetry_id>3650 );

包含Exists的SQL语句:

select from t_author ta where exists

(select * from t_poetry tp where tp.poetry_id>3650 and tp.author_id=ta.author_id);

第一次实验

数据情况

t_author表,13355条记录;t_poetry表,子查询筛选结果集 where poetry_id>293650 ,121条记录;

执行结果

使用exists耗时0.94S, 使用in耗时0.03S,<font color=red>IN 效率高于Exists</font>。

原因分析

对t_poetry表的子查询结果集很小,且两者在t_poetry表都能使用索引,对t_poetry子查询的消耗基本一致。两者区别在于,使用 in 时,t_author表能使用索引:

使用exists时,t_author表全表扫描:

在子查询结果集较小时,查询耗时主要表现在对t_author表的遍历上。

第二次实验

数据情况

t_author表,13355条记录;t_poetry表,子查询筛选结果集 where poetry_id>3650 ,287838条记录;

执行时间

使用exists耗时0.12S, 使用in耗时0.48S,<font color=red>Exists IN</font>。

原因分析

两者的索引使用情况跟第一次实验是一致的,唯一区别是子查询筛选结果集的大小不同,但实验结果已经跟第一次的不同了。这种情况下子查询结果集很大,我们看看mysql的查询计划:

使用in时,由于子查询结果集很大,对t_author和t_poetry表都接近于全表扫描,此时对t_author表的遍历耗时差异对整体效率影响可以忽略,执行计划里多了一行<auto_key>,在接近全表扫描的情况下,mysql优化器选择了auto_key来遍历t_author表:

使用exists时,数据量的变化没有带来执行计划的改变,但由于子查询结果集很大,5.5以后的MySQL版本在exists匹配查询结果时使用的是Block Nested-Loop(Block嵌套循环,引入join buffer,类似于缓存功能)开始对查询效率产生显著影响,尤其针对<font color=red>子查询结果集很大</font>的情况下能显著改善查询匹配效率:

实验结论

根据上述两个实验及实验结果,我们可以较清晰的理解IN 和Exists的执行过程,并归纳出IN 和Exists的适用场景:

  • IN查询在内部表和外部表上都可以使用到索引;
  • Exists查询仅在内部表上可以使用到索引;
  • 当子查询结果集很大,而外部表较小的时候,Exists的Block Nested Loop(Block 嵌套循环)的作用开始显现,并弥补外部表无法用到索引的缺陷,查询效率会优于IN。
  • 当子查询结果集较小,而外部表很大的时候,Exists的Block嵌套循环优化效果不明显,IN 的外表索引优势占主要作用,此时IN的查询效率会优于Exists。
  • 网上的说法不准确。其实“表的规模”不是看内部表和外部表,而是外部表和子查询结果集。
  • 最后一点,也是最重要的一点:世间没有绝对的真理,掌握事物的本质,针对不同的场景进行实践验证才是最可靠有效的方法。

实验过程中发现的问题补充

仅对不同数据集情况下的上述exists语句分析时发现,数据集越大,消耗的时间反而变小,觉得很奇怪。

具体查询条件为:

where tp.poetry_id>3650,耗时0.13S

where tp.poetry_id>293650,耗时0.46S

可能原因:条件值大,查询越靠后,需要遍历的记录越多,造成最终消耗越多的时间。这个解释有待进一步验证后再补充。

MySQL查询语句中的IN 和Exists 对比分析相关推荐

  1. 【力荐】Select查询语句中LIKE关键词的优化方法分析

    今天接到一个优化需求,跑个程序要12+个小时,周期是每天一次,所以时效性极差,不能响应快速的实际业务需求,下面我们看一段LIKE的优化方法. SELECT     bukrs werks lgort ...

  2. MyBatis + MyBatis Plus + MySQL——查询语句中字段名为MySQL关键字问题解决方案

    问题描述 ### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You have an error in your ...

  3. php无法查询mysql字母,php – 无法在Multi MYSQL查询语句中获取结果

    ==已解决== 我从以下帖子中获得此查询: 我在phpMyAdmin上试了一下,看到了我想要但无法获取的结果. $query = "SET @order_id := '', @order_t ...

  4. mysql查询语句 变量_mysql查询语句中用户变量的使用

    先上代码吧 SELECT `notice`.`id` , `notice`.`fid` , `notice`.`has_read` , `notice`.`notice_time` , `notice ...

  5. Mysql 子查询 (查询语句中带查询语句)

    子查询:指一个"正常查询语句"中的某个部分(比如select部分,from 部分,where 部分)又出现了查询的一种查询形式,比如: select * from 表名 where ...

  6. mysql五大子句_MySQL的查询语句中可以使用以下哪个子句来表示分组查询

    [多选题]人类行为遗传学工作者倾向于把人的行为遗传分为哪几类 [填空题]MySQL的连接操作包括内连接.( )和交叉连接. [判断题]社会生活类尤其是人文风光类纪录片的解说则多用文学. 散文手法, 既 ...

  7. mysql 数据库里查询语句中不等于的两种写法

    mysql 数据库里查询语句中不等于的两种写法 ps:本人亲测,阿里云2核4G5M的服务器性价比很高,新用户一块多一天,老用户三块多一天,最高可以买三年,感兴趣的可以戳一下:阿里云折扣服务器 1.my ...

  8. mysql 中like用法_mysql查询语句中like 的用法

    1.常见用法: (1)搭配%使用 %代表一个或多个字符的通配符,譬如查询字段name中以大开头的数据: (2)搭配_使用 _代表仅仅一个字符的通配符,把上面那条查询语句中的%改为_,会发现只能查询出一 ...

  9. php面试专题---MYSQL查询语句优化

    php面试专题---MYSQL查询语句优化 一.总结 一句话总结: mysql的性能优化包罗甚广: 索引优化,查询优化,查询缓存,服务器设置优化,操作系统和硬件优化,应用层面优化(web服务器,缓存) ...

最新文章

  1. C#如何安全、高效地玩转任何种类的内存之Span的秉性特点(二)
  2. Mesos源码分析(9): Test Framework的启动
  3. java上传文件-大文件以二进制保存到数据库
  4. SuperSocketClientEngine
  5. ESP8266 ESP8089 ESP8285 用户手册文档汇总
  6. Java常用代码汇总(经典代码)
  7. 实例!AGV与MES对接的智能仓储系统设计
  8. JAVA 解析json字符串常用方法
  9. Twaver-HTML5基础学习(1)两点一线
  10. word论文页码排版
  11. java anon,shiro anon 不生效
  12. Unity 的阴影实现原理
  13. 面试题:你的缺点是什么?(为难我?怎么可能)
  14. beats耳机红白交替闪烁三次_beats耳机红白灯交替闪如何解决
  15. 搞一个win7下能运行的免费财务软件 快马财务软件 v1.0
  16. DE、SaDE、JADE、SHADE、L-SHADE算法整理
  17. 除了阿里云服务器,还有什么便宜的服务器值得推荐?
  18. 三种代码版本控制系统的简介 以及 SVN的安装
  19. 【这个太强了】微信超级管家,支持自动回复、好友计数、自动同意、群发、好友导出、消息日志、无限多开
  20. 使用ESP-8266模块做一个便携式WIFI杀手

热门文章

  1. 实验详解——Cobbler自动部署最小化安装
  2. jdbc 自增id 原理_面试被问分布式ID怎么办? 滴滴(Tinyid)甩给他
  3. access数据类型百度百科_Day 7 基本数据类型
  4. Android程序员 2019,VS 2019开发APP(一)界面和代码
  5. java做一个客房管理系统定制_管理皮孩子很难?来,教你一个java设计简单的学生管理系统...
  6. mysql触发器行锁_MySQL 之 视图、触发器、存储过程、函数、事物与数据库锁
  7. ad19pcb所有元件都在报错_PLC的线圈输出和置复位,可以混用吗?很多人都会犯这个错误!...
  8. html文件如何放到服务器上_对网盘泄露说不,自己数据放到自己服务器上,用群辉搭建个人网盘...
  9. 人脸识别三大经典算法_人脸识别系列四 | DeepID1算法
  10. hibernate oracle驱动,出错场景是升级oracle驱动,将版本从ojdbc14升级到ojdbc6,hibernate执行原生态sql语句会报如下错误...