ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

眼睁睁地踩到 MySQL in 子查询的“坑”

2021-03-22 19:51:22  阅读:265  来源: 互联网

标签:author 查询 subquery select MySQL where id 眼睁睁 userinfo


眼睁睁地踩到 MySQL in 子查询的“坑”

PlatformDev 360云计算

女主宣言

什么情况? 一个简单的 SQL 子查询,在几万条记录中查询,竟然用了 33 秒!快来看看,怎么跳过这个坑。
PS:丰富的一线技术、多元化的表现形式,尽在“HULK一线技术杂谈”,点关注哦!

前言

MySQL 是项目中常用的数据库,其中 in 查询也是很常用。最近项目调试过程中,遇到一个出乎意料的 select 查询,竟然用了 33 秒!

一、表结构

1. userinfo 表
眼睁睁地踩到 MySQL in 子查询的“坑”

2. article 表
眼睁睁地踩到 MySQL in 子查询的“坑”

二、问题 SQL 实例

select * from userinfo where id in (select author_id from artilce where type = 1);

大家第一眼看到上面的 SQL 时,可能都会觉得这是一个很简单的子查询。先把 author_id 查出来,再用 in 查询一下。

如果有相关索引会非常快的,拆解来讲就是以下这样的:

  1. select author_id from artilce where type = 1;
  2. select * from userinfo where id in (1,2,3);

但是事实是这样的:

mysql> select count(*) from userinfo;
眼睁睁地踩到 MySQL in 子查询的“坑”

mysql> select count(*) from article;
眼睁睁地踩到 MySQL in 子查询的“坑”

mysql> select id,username from userinfo where id in (select author_id from article where type = 1);
眼睁睁地踩到 MySQL in 子查询的“坑”

33 秒!为什么会这么慢呢?

三、问题原因

官方文档解释:in 子句在查询的时候有时会被转换为 exists 的方式来执行,变成逐条记录进行遍历(版本 5.5 中存在,5.6 中已做优化)。

眼睁睁地踩到 MySQL in 子查询的“坑”
参考:
https://dev.mysql.com/doc/refman/5.5/en/subquery-optimization.html

四、解决方式(版本 5.5)

1. 使用临时表


select id,username from userinfo 
where id in (select author_id from 
    (select author_id from article where type = 1) as tb
);

眼睁睁地踩到 MySQL in 子查询的“坑”

2. 使用 join


select a.id,a.username from userinfo a, article b 
where a.id = b.author_id and b.type = 1;

眼睁睁地踩到 MySQL in 子查询的“坑”

五、补充

版本 5.6 已针对子查询做了优化,方式跟【四】中的临时表方式一样,参考官方文档:


If materialization is not used, the optimizer sometimes rewrites a noncorrelated subquery as a correlated subquery.

For example, the following IN subquery is noncorrelated  ( where_condition involves only columns from t2 and not t1 ):

select * from t1 
where t1.a in (select t2.b from t2 where where_condition);

The optimizer might rewrite this as an EXISTS correlated subquery:

select * from t1 
where exists (select t2.b from t2 where where_condition and t1.a=t2.b);

Subquery materialization using a temporary table avoids such rewrites and makes it possible to execute the subquery only once rather than once per row of the outer query.

https://dev.mysql.com/doc/refman/5.6/en/subquery-materialization.html

标签:author,查询,subquery,select,MySQL,where,id,眼睁睁,userinfo
来源: https://blog.51cto.com/15127564/2668518

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有