本文对比了MySQL中IN子查询与JOIN查询的性能差异，并通过实测表明在MySQL 5.7.18版本中，IN子查询可能导致索引无法被利用，而JOIN查询则能有效提升查询效率。
来源：http://www.jb51.net/article/117412.htm
今天看到一篇关于MySQL的IN子查询优化的案例，
一开始感觉有点半信半疑（如果是换做在SQL Server中，这种情况是绝对不可能的，后面会做一个简单的测试。）
随后动手按照他说的做了一个表来测试验证，发现MySQL的IN子查询做的不好，确实会导致无法使用索引的情况（IN子查询无法使用所以，场景是MySQL，截止的版本是5.7.18）
MySQL的测试环境
测试表如下
|
1
2
3
4
5
6
7
|
create
table
test_table2
(
id
int
auto_increment
primary
key
,
pay_id
int
,
pay_time datetime,
other_col
varchar
(100)
)
|
建一个存储过程插入测试数据，测试数据的特点是pay_id可重复，这里在存储过程处理成，循环插入300W条数据的过程中，每隔100条数据插入一条重复的pay_id，时间字段在一定范围内随机
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
CREATE
DEFINER=`root`@`%`
PROCEDURE
`test_insert`(
IN
`loopcount`
INT
)
LANGUAGE SQL
NOT
DETERMINISTIC
CONTAINS
SQL
SQL SECURITY DEFINER
COMMENT
''
BEGIN
declare
cnt
int
;
set
cnt = 0;
while cnt< loopcount do
insert
into
test_table2 (pay_id,pay_time,other_col)
values
(cnt,date_add(now(), interval floor(300*rand())
day
),uuid());
if (cnt mod 100 = 0)
then
insert
into
test_table2 (pay_id,pay_time,other_col)
values
(cnt,date_add(now(), interval floor(300*rand())
day
),uuid());
end
if;
set
cnt = cnt + 1;
end
while;
END
|
执行 call test_insert(3000000); 插入303000行数据
两种子查询的写法
查询大概的意思是查询某个时间段之内的业务Id大于1的数据，于是就出现两种写法。
第一种写法如下：IN子查询中是某段时间内业务统计大于1的业务Id，外层按照IN子查询的结果进行查询，业务Id的列pay_id上有索引，逻辑也比较简单，这种写法，在数据量大的时候确实效率比较低，用不到索引
|
1
2
3
4
5
6
7
8
|
select
*
from
test_table2
force
index
(idx_pay_id)
where
pay_id
in
(
select
pay_id
from
test_table2
where
pay_time>=
"2016-06-01 00:00:00"
AND
pay_time<=
"2017-07-03 12:59:59"
group
by
pay_id
having
count
(pay_id) > 1
);
|
执行结果：2.23秒
第二种写法，与子查询进行join关联，这种写法相当于上面的IN子查询写法，下面测试发现，效率确实有不少的提高
|
1
2
3
4
5
6
7
8
9
10
|
select
tpp1.*
from
test_table2 tpp1,
(
select
pay_id
from
test_table2
WHERE
pay_time>=
"2016-07-01 00:00:00"
AND
pay_time<=
"2017-07-03 12:59:59"
group
by
pay_id
having
count
(pay_id) > 1
) tpp2
where
tpp1.pay_id=tpp2.pay_id
|
执行结果：0.48秒
In子查询的执行计划，发现外层查询是一个全表扫描的方式，没有用到pay_id上的索引
join自查的执行计划，外层（tpp1别名的查询）是用到pay_id上的索引的。
后面想对第一种查询方式使用强制索引，虽然是不报错的，但是发现根本没用
如果子查询是直接的值，则是可以正常使用索引的。
可见MySQL对IN子查询的支持，做的确实不怎么样。
另外：加一个使用临时表的情况，虽然比不少join方式查询的，但是也比直接使用IN子查询效率要高，这种情况下，也是可以使用到索引的，不过这种简单的情况，是没有必要使用临时表的。
下面是类似案例在sqlserver 2014中的测试，几万完全一样的测试表结构和数量，可见这种情况下，两种写法，在SQL Server中可以认为是完全一样的（执行计划+效率），这一点SQL Server要比MySQL强不少
下面是sqlserver中的测试环境脚本。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
create table test_table2
(
id int identity(1,1) primary key,
pay_id int,
pay_time datetime,
other_col varchar(100)
)
begin tran
declare @i int = 0
while
@i<300000
begin
insert into test_table2 values (@i,getdate()-rand()*300,newid());
if
(@i%1000=0)
begin
insert into test_table2 values (@i,getdate()-rand()*300,newid());
end
set @i = @i + 1
end
COMMIT
GO
create index idx_pay_id on test_table2(pay_id);
create index idx_time on test_table2(pay_time);
GO
select * from test_table2
where pay_id
in
(
select pay_id from test_table2
where pay_time>=
'2017-01-21 00:00:00'
AND pay_time<=
'2017-07-03 12:59:59'
group by pay_id
having count(pay_id) > 1
);
select tpp1.* from test_table2 tpp1,
(
select pay_id
from test_table2
WHERE pay_time>=
'2017-01-21 00:00:00'
AND pay_time<=
'2017-07-30 12:59:59'
group by pay_id having
count(pay_id) > 1
) tpp2
where tpp1.pay_id=tpp2.pay_id
|
总结：在MySQL数据中，截止5.7.18版本，对IN子查询，仍要慎用
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
