它的執行計劃如下，請注意看關鍵詞“DEPENDENT SUBQUERY”：

id? select_type???????? table?? type??????????? possible_keys?????????????????????????? key?????????? key_len? ref?????? rows? Extra

------? ------------------? ------? --------------? --------------------------------------? ------------? -------? ------? ------? -----------

1? PRIMARY???????????? g1????? index?????????? (NULL)????????????????????????????????? idx_gid? 5??????? (NULL)? 850672Using 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 wherestatus=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 andg1.gid=g2.gid

GROUP BY g1.gid;

也能得到同樣的結果，且是毫秒級。

它的執行計劃為：

id? select_type? table?????????? type??? possible_keys????????????? key??????????? key_len? ref??????????? rows? Extra

------? -----------? --------------? ------? -------------------------? -------------? -------? -----------? ------? -------------------------------

1? PRIMARY????? ????? 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? DERIVEDshop_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》吧)

總結

以上是生活随笔為你收集整理的mysql子查询缺点_[慢查优化]慎用MySQL子查询，尤其是看到DEPENDENT SUBQUERY标记时的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。