mysql子查询慢的问题

当你在用explain工具查看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;

用explain看了一下。出现keyword“DEPENDENT SUBQUERY”。意味着子查询的第一个select依赖外部的查询;

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万次……即使这两步查询都用到了索引，但不慢才怪；

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

对于此类语句一般的优化策略是拆成两个查询语句。你不想拆成两个独立查询的话，也能够与暂时表join查询，：

你不想拆成两个独立查询的话，也能够与暂时表联表查询，例如以下所看到的优化后的sql：

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;

用explain看了一下，这次又有了一个新的keyword"DERIVED"，意思是用于 from 子句里有子查询的情况。MySQL 会递归运行这些子查询，把结果放在暂时表里，然后再做join操作；

DERIVED 的官方含义为：用于 from 子句里有子查询的情况。MySQL 会递归运行这些子查询，把结果放在暂时表里。

《高性能MySQL》的第4.4节“MySQL查询优化器的限制（Limitations of the MySQL Query Optimizer）”之第4.4.1小节“关联子查询（Correlated Subqueries）”也有相似的论述：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 表非常大的话，那么性能上将会出现故障。