258资源分享网

嵌套查询糟糕的优化 在上面我提到过，不考虑特殊的情况，联表查询要比嵌套查询更有效。尽管两条查询表达的是同样的意思，尽管你的计划是告诉服务器要做什么，然后让它决定怎么做，但有时候你非得告诉它改怎么做。否则优化器可能会做傻事。我最近就碰到这样的情况。这几个表是三层分级关系：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]  复制代码 代码如下: