[慢查優化]慎用MySQL子查詢，尤爲是看到DEPENDENT SUBQUERY標記時

案例梳理時間：2013-9-25

寫在前面的話：

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)的實現；

2，2012，iteye，MySQL子查詢很慢的問題；

3，2011，hidba，mysql子查詢的弱點 和 生產庫中遇到mysql的子查詢；

慢查系列：

[慢查優化]建索引時注意字段選擇性 & 範圍查詢注意組合索引的字段順序

[慢查優化]聯表查詢注意誰是驅動表 & 你搞不清楚誰join誰更好時請放手讓mysql自行斷定

贈圖幾枚：

@易度-潘俊勇:

許式偉的這個ppt，涵蓋了他全部對golang的理解，推薦你們閱讀： http://t.cn/zRI8tIH

 

-over-