mysql数据库中 IN 和 EXISTS 的误区

前言：最近在看《高性能mysql第三版》这本书，读到子查询优化那章，书中说mysql会将in子查询改写成exists查询（书中基于的mysql版本是5.1.50和5.5），于是乎我又上网找了下资料，发现网上说法几乎都是：

in 子查询是把外表和内表hash关联，先查询内表，再把内表结果与外表匹配，对外表使用索引（外表效率高，可用大表），而内表多大都需要查询，不可避免，故外表大的使用in，可加快效率。

exists 是对外表做loop循环，每次loop循环再对内表（子查询）进行查询，那么因为对内表的查询使用的索引（内表效率高，故可用大表），而外表有多大都需要遍历，不可避免（尽量用小表），故内表大的使用exists，可加快效率；

发现竟然和书上说的不一样，因为按照书上说所，in 和 exists 应该是一样的（会重写 in 查询为 exists ) ，于是想在本地mysql测试一下，本地装的是5.7版本，数据库中有两个表 userinfo 和 syslog 表：

这里使用两个表的主键id进行关联，sql 和分析计划表如下：

explain  select * from syslog where id in(select id from userinfo);

show WARNINGS;

可以看到优先执行userinfo表，再去和syslog进行比对，看起来似乎和网上说的一样，接着我们将顺序颠倒：

explain  select * from userinfo where id in(select id from syslog);

show WARNINGS;

结果竟然和上面执行计划运行顺序是一致的？？？我们打开结果二那一栏查看mysql优化器将sql重写后的结果，分别如下：

原SQL：
select * from syslog where id in(select id from userinfo);
优化后的SQL：
/* select#1 */
SELECT
	`test`.`syslog`.`id` AS `id`,
	`test`.`syslog`.`user_name` AS `user_name`,
	`test`.`syslog`.`type` AS `type`,
	`test`.`syslog`.`operation` AS `operation`,
	`test`.`syslog`.`method` AS `method`,
	`test`.`syslog`.`params` AS `params`,
	`test`.`syslog`.`ip` AS `ip`,
	`test`.`syslog`.`operation_time` AS `operation_time`
FROM
	`test`.`userinfo`
JOIN `test`.`syslog`
WHERE
	(
		`test`.`syslog`.`id` = `test`.`userinfo`.`id`
	)

原SQL：
select * from userinfo where id in(select id from syslog);
优化后的SQL：
/* select#1 */
SELECT
	`test`.`userinfo`.`id` AS `id`,
	`test`.`userinfo`.`user_id` AS `user_id`,
	`test`.`userinfo`.`user_name` AS `user_name`,
	`test`.`userinfo`.`age` AS `age`,
	`test`.`userinfo`.`gender` AS `gender`,
	`test`.`userinfo`.`address` AS `address`,
	`test`.`userinfo`.`user_pass` AS `user_pass`
FROM
	`test`.`syslog`
JOIN `test`.`userinfo`
WHERE
	(
		`test`.`userinfo`.`id` = `test`.`syslog`.`id`
	)

可以看到 mysql将两个in子查询全都改写成了内连接查询 ，这也就可以解释两个分析计划表为什么总是先查找userinfo表了，因为在内连接的情况下mysql优化器始终会先访问数据量小的那张表，这样可以减少不必要的IO。

第一个sql改写后首先运行的是 select id from userinfo 使用了主键覆盖索引（Extra 为 using index），将查询的结果和 syslog 进行匹配，所以syslog表使用了主键索引+where条件过滤（Extra 为 using Where）。

第二个sql改写后首先运行的的是 select * from userinfo ，所以计划中显示的是全表扫描，然后将查询后的结果和 syslog 进行匹配，这里因为查找的是select id from syslog where id = ? ，所以计划中显示是覆盖索引+where条件过滤（Extra 为 using where + using index)。

我们再来看一下 exists 的分析情况：

explain select * from syslog where exists(select * from userinfo where userinfo.id = syslog.id);

explain select * from userinfo where exists(select * from syslog where syslog.id = userinfo.id);

可以看到exists查询是一个相关子查询，内部的查询需要依赖外部的查询结果，所以两个sql的分析计划都是先将外部的表进行全表扫描再和子查询表进行比对，如果外部的表数据量小的话性能可能不会太差，数据量大的情况下性能会非常糟糕。

结论：1、mysql5.5以前会将 in 子查询改写成 exists 查询，如果外部表数据量大的情况下性能会非常糟糕。

2、mysql5.7（5.6没有测过，感兴趣的同学可以测测）对 in 子查询进行了优化，会将sql改写成 join 连接，这样优化器就可以始终优先访问数据量小的表格，减少IO，性能和直接写连接查询几乎是一样的（这点和网上书上说的是有出入的）。

3、exists查询会被分解成一个外部查询和相关子查询（DEPENDENT SUBQUERY），这样子查询会依赖于外部查询的结果，所以始终会对外部表进行全表扫描，外部表数据量大的时候要尤其注意。

mysql数据库中 IN 和 EXISTS 的误区

猜你喜欢