mysql嵌套查询和联表查询优化方法

嵌套查询糟糕的优化在上面我提到过,不考虑特殊的情况,联表查询要比嵌套查询更有效。尽管两条查询表达的是同样的意思,尽管你的计划是告诉服务器要做什么,然后让它决定怎么做,但有时候你非得告诉它改怎么做。否则优化器可能会做傻事。我最近就碰到这样的情况。这几个表是三层分级关系:category, subcategory和item。有几千条记录在category表,几百条记录在subcategory表,以及几百万条在item表。你可以忽略category表了,我只是交代一下背景,以下查询语句都不涉及到它。这是创建表的语句: [sql] 复制代码 代码如下:  create table subcategory ( id int not null primary key, category int not null, index(category) ) engine=InnoDB;  create table item( id int not null auto_increment primary key, subcategory int not null, index(subcategory) ) engine=InnoDB;  我又往表里面填入一些样本数据  [sql] 复制代码 代码如下:  insert into subcategory(id, category) select i, i/100 from number where i <= 300000;  insert into item(subcategory) select id from ( select id, rand() * 20 as num_rows from subcategory ) as x cross join number where i <= num_rows;  create temporary table t as select subcategory from item group by subcategory having count(*) = 19 limit 100;  insert into item (subcategory) select subcategory from t cross join number where i < 2000;  再次说明,这些语句运行完需要一点时间,不适合放在产品环境中运行。思路是往item里插入随机行数的数据,这样subcategory就有1到2018之间个item。这不是实际中的完整数据,但效果一样。 我想找出某个category中item数大于2000的全部subcategory。首先,我找到一个subcategory item数大于2000的,然后把它的category用在接下来的查询中。这是具体的查询语句: [sql] 复制代码 代码如下:  select c.id from subcategory as c inner join item as i on i.subcategory = c.id group by c.id having count(*) > 2000;  -- choose one of the results, then select * from subcategory where id = ???? -- result: category = 14  我拿到一个合适的值14,在以下的查询中会用到它。这是用来查询category 14 中所有item数大于2000的subcategory的语句: [sql] 复制代码 代码如下:  select c.id from subcategory as c inner join item as i on i.subcategory = c.id where c.category = 14 group by c.id having count(*) > 2000;  在我的样例数据里,查询的结果有10行记录,而且只用10多秒就完成了。EXPLAIN显示出很好地使用了索引;从数据的规模来看,相当不错了。查询计划是在索引上遍历并计算出目标记录。目前为止,非常好。 这回假设我要从subcategory取出全部的字段。我可以把上面的查询当成嵌套,然后用JOIN,或者SELECT MAX之类(既然分组集对应的值都是唯一的),但也写成跟下面的一样的,有木有? [sql] 复制代码 代码如下:  select * from subcategory where id in ( select c.id from subcategory as c inner join item as i on i.subcategory = c.id where c.category = 14 group by c.id having count(*) > 2000 );  跑完这条查询估计要从破晓到夕阳沉入大地。我不知道它要跑多久,因为我没打算让它无休止地跑下去。你可能认为,单从语句上理解,它会:a)计算出里面的查询,找出那10个值,b)继续找出那10条记录,并且在primary索引上去找会非常地快。错,这是实际上的查询计划: [sql] 复制代码 代码如下:  *************************** 1. row *************************** id: 1 select_type: PRIMARY table: subcategory type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 300783 Extra: Using where *************************** 2. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: c type: ref possible_keys: PRIMARY,category key: category key_len: 4 ref: const rows: 100 Extra: Using where; Using index; Using temporary; Using filesort *************************** 3. row *************************** id: 2 select_type: DEPENDENT SUBQUERY table: i type: ref possible_keys: subcategory key: subcategory key_len: 4 ref: c.id rows: 28 Extra: Using index  如何你不熟悉如何分析mysql的语句查询计划,请看大概意思:mysql计划从外到内执行查询,而不是从内到外。我会一个一个地介绍查询的每个部分。 外面的查询简单地变成了SELECT * FROM subcategory。虽然里面的查询对subcategory有个约束(WHERE category = 14),但出于某些原因mysql没有将它作用于外面的查询。我不知道是神马原因。我只知道它扫描了整张表(这就是 type:ALL 表示的意思),并且没有使用任何的索引。这是在10几万行记录的表上扫描。 在外面的查询,对每行都执行一次里面的查询,尽管没有值被里面的查询使用到,因为里面的查询被“优化”成引用外面的查询。照此分析,查询计划变成了嵌套循环。外面的查询的每一次循环,都执行一次里面的查询。下面就是优化器重写后的查询计划: [sql] 复制代码 代码如下: