[慢查优化]慎用MySQL子查询，尤其是看到DEPENDENT SUBQUERY标记时

拼搏现实的明天。 2023-02-18 09:50 16阅读 0赞

写在前面的话：

1.  在慢查优化[1][]和[2][]里都反复强调过 explain 的重要性，但有时候肉眼看不出 explain 结果如何指导优化，这时候还需要有一些其他基础知识的佐助，**甚至需要了解 MySQL 实现原理，如子查询慢查优化**。
2.  看到 SQL 执行计划中 select\_type 字段中出现“**DEPENDENT SUBQUERY**”时，要打起精神了！

--------------------

**——MySQL 的子查询为什么有时候很糟糕——**

**引子：这样的子查询为什么这么慢？**

下面的例子是一个慢查，线上执行时间相当夸张。为什么呢？

SELECT gid,COUNT(id) as count 
    
    FROM shop_goods g1
    
    WHERE status =0 and gid IN ( 
    
    SELECT gid FROM shop_goods g2 WHERE sid IN  (1519066,1466114,1466110,1466102,1466071,1453929)
    
    )
    
    GROUP BY gid;

它的执行计划如下，请注意看关键词“DEPENDENT SUBQUERY”：

id  select\_type         table   type            possible\_keys                           key           key\_len  ref       rows  Extra        
\------  ------------------  ------  --------------  --------------------------------------  ------------  -------  ------  ------  -----------  
     1  PRIMARY             **g1**      index           (NULL)                                  idx\_gid  5        (NULL)  **850672  **Using where  
     2  **DEPENDENT SUBQUERY**  **g2**      index\_subquery  id\_shop\_goods,idx\_sid,idx\_gid  idx\_gid  5        func         1  Using where

**基础知识：Dependent Subquery意味着什么**

官方含义为：

> SUBQUERY：子查询中的第一个SELECT；
> 
> DEPENDENT SUBQUERY：子查询中的第一个SELECT，**取决于外面的查询** 。

换句话说，就是 **子查询对 g2 的查询方式依赖于外层 g1 的查询**。

什么意思呢？它意味着两步：

第一步，MySQL 根据 select gid,count(id) from shop\_goods where **status=0 group by gid**; 得到一个大结果集 t1，其数据量就是上图中的 rows=850672 了。

第二步，上面的大结果集 t1 中的每一条记录，都将与子查询 SQL 组成新的查询语句：select gid from shop\_goods where sid in (15...blabla..29) and gid=%t1.gid%。等于说，**子查询要执行85万次**……即使这两步查询都用到了索引，但不慢才怪。

如此一来，**子查询的执行效率居然受制于外层查询的记录数，那还不如拆成两个独立查询顺序执行呢**。

**优化策略1：**

你不想拆成两个独立查询的话，也可以**与临时表联表查询**，如下所示：

SELECT g1.gid,count(1)
    
    FROM shop_goods g1,(select gid from shop_goods WHERE sid in (1519066,1466114,1466110,1466102,1466071,1453929)) g2
    
    where g1.status=0 and g1.gid=g2.gid
    
    GROUP BY g1.gid;

也能得到同样的结果，且是毫秒级。

它的执行计划为：

id  select\_type  table           type    possible\_keys              key            key\_len  ref            rows  Extra                            
\------  -----------  --------------  ------  -------------------------  -------------  -------  -----------  ------  -------------------------------  
     1  PRIMARY      **<derived2>**      ALL     (NULL)                     (NULL)         (NULL)   (NULL)           30  Using temporary; Using filesort  
     1  PRIMARY      g1              ref     idx\_gid               idx\_gid   5        g2.gid       1  Using where                      
     2  **DERIVED      **shop\_goods  range   id\_shop\_goods,idx\_sid  id\_shop\_goods  5        (NULL)           30  Using where; Using index

DERIVED 的官方含义为：

DERIVED：用于 from 子句里有子查询的情况。MySQL 会递归执行这些子查询，把结果放在临时表里。

**DBA观点引用：MySQL 子查询的弱点**

hidba 论述道（*参考资源3*）：

> mysql 在处理子查询时，会改写子查询。
> 
> 通常情况下，我们希望由内到外，先完成子查询的结果，然后再用子查询来驱动外查询的表，完成查询。
> 
> 例如：
> 
> select \* from test where tid in(select fk\_tid from sub\_test where gid=10)
> 
> 通常我们会感性地认为该 sql 的执行顺序是：
> 
> **sub\_test 表中根据 gid 取得 fk\_tid(2,3,4,5,6)记录，**
> 
> **然后再到 test 中，带入 tid=2,3,4,5,6，取得查询数据。**
> 
> 但是实际mysql的处理方式为：
> 
> select \* from test where exists (
> 
> select \* from sub\_test where gid=10 and sub\_test.fk\_tid=test.tid
> 
> )
> 
> mysql 将会扫描 test 中所有数据，每条数据都将会传到子查询中与 sub\_test 关联，子查询不会先被执行，所以如果 test 表很大的话，那么性能上将会出现问题。

**《高性能MySQL》一书的观点引用**

《高性能MySQL》的第4.4节“MySQL查询优化器的限制（Limitations of the MySQL Query Optimizer）”之第4.4.1小节“关联子查询（Correlated Subqueries）”也有类似的论述：

> MySQL有时优化子查询很糟，特别是在WHERE从句中的IN()子查询。……
> 
> 比如在sakila数据库sakila.film表中找出所有的film，这些film的actoress包括Penelope Guiness(actor\_id = 1)。可以这样写：
> 
> mysql> SELECT \* FROM sakila.film
> 
> \-> WHERE film\_id IN(
> 
> \-> SELECT film\_id FROM sakila.film\_actor WHERE actor\_id = 1);
> 
> mysql> EXPLAIN SELECT \* FROM sakila.film ...;
> 
> \+----+--------------------+------------+--------+------------------------+
> 
> | id | select\_type        | table      | type   | possible\_keys          |
> 
> \+----+--------------------+------------+--------+------------------------+
> 
> | 1  | PRIMARY            | film       | ALL    | NULL                   |
> 
> | 2  | **DEPENDENT SUBQUERY** | film\_actor | eq\_ref | PRIMARY,idx\_fk\_film\_id |
> 
> \+----+--------------------+------------+--------+------------------------+
> 
> 根据EXPLAIN的输出，MySQL将全表扫描film表，对找到的每行执行子查询，这是很不好的性能。幸运的是，很容易改写为一个join查询：
> 
> mysql> SELECT film.\* FROM sakila.film
> 
> \-> INNER JOIN sakila.film\_actor USING(film\_id)
> 
> \-> WHERE actor\_id = 1;
> 
> 另外一个方法是**通过使用GROUP\_CONCAT()执行子查询作为一个单独的查询，手工产生IN()列表。有时候比join还快**。（注：你不妨在我们的库上试试看 SELECT goods\_id,GROUP\_CONCAT(cast(id as char))
> 
> FROM bee\_shop\_goods
> 
> WHERE shop\_id IN (1519066,1466114,1466110,1466102,1466071,1453929)
> 
> GROUP BY goods\_id;）
> 
> MySQL已经因为这种特定类型的子查询执行计划而被批评。
> 
>  
> 
> **何时子查询是好的**
> 
> MySQL并不总是把子查询优化得很糟。有时候还是很优化的。下面是个例子：
> 
> mysql> EXPLAIN SELECT film\_id, language\_id FROM sakila.film
> 
> \-> WHERE NOT EXISTS(
> 
> \-> SELECT \* FROM sakila.film\_actor
> 
> \-> WHERE film\_actor.film\_id = film.film\_id
> 
> \-> )G
> 
> ……（注：具体文字还是请阅读《高性能MySQL》吧）

是的，子查询并不是总是被优化得很糟糕，具体问题具体分析，但别忘了 explain 。

**参考资源：**

1，2011，wudongxu，[mysql子查询(in)的实现][mysql_in]；

2，2012，iteye，[MySQL子查询很慢的问题][MySQL]；

3，2011，hidba，[mysql子查询的弱点][mysql] 和 [生产库中遇到mysql的子查询][mysql 1]；

[1]: http://www.cnblogs.com/zhengyun_ustc/p/slowquery1.html
[2]: http://www.cnblogs.com/zhengyun_ustc/p/slowquery2.html
[mysql_in]: http://blog.csdn.net/wudongxu/article/details/6966052
[MySQL]: http://codingstandards.iteye.com/blog/1344833
[mysql]: http://hidba.org/?p=260
[mysql 1]: http://hidba.org/?p=412