解决MySQL中IN子查询会导致无法使用索引问题

站长资源 2024/11/24 佚名

2 0 1

今天看到一篇关于MySQL的IN子查询优化的案例，

一开始感觉有点半信半疑（如果是换做在SQL Server中，这种情况是绝对不可能的，后面会做一个简单的测试。）

随后动手按照他说的做了一个表来测试验证，发现MySQL的IN子查询做的不好，确实会导致无法使用索引的情况（IN子查询无法使用所以，场景是MySQL，截止的版本是5.7.18）

MySQL的测试环境

测试表如下

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，时间字段在一定范围内随机

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上有索引，逻辑也比较简单，这种写法，在数据量大的时候确实效率比较低，用不到索引

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子查询写法，下面测试发现，效率确实有不少的提高

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中的测试环境脚本。

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子查询，仍要慎用

mysql,子查询,索引,mysql中in子查询

广告合作：本站广告合作请联系QQ：858582 申请时备注：广告合作（否则不回）
免责声明：本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除！

评论“解决MySQL中IN子查询会导致无法使用索引问题”

暂无评论...

《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒经典版》的玩家都可以获得奖励。

更新日志

2024年11月24日

解决MySQL中IN子查询会导致无法使用索引问题

Mysql在Windows系统快速安装部署方法（绿色免安装版）

解决MySQL因不能创建 PID 导致无法启动的方法

评论“解决MySQL中IN子查询会导致无法使用索引问题”

《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线

更新日志

友情链接