一，嵌套查询糟糕的优化
不考虑特殊的情况，联表查询要比嵌套查询更有效。尽管两条查询表达的是同样的意思，尽管计划是告诉服务器要做什么，然后让它决定怎么做，但有时非得告诉它改怎么做。否则优化器可能会做傻事。
这几个表是三层分级关系：category, subcategory和item。
有几千条记录在category表，几百条记录在subcategory表，以及几百万条在item表。你可以忽略category表了，我只是交代一下背景，以下查询语句都不涉及到它。
创建表的语句：
复制代码 代码示例:
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;
又往表里面填入一些样本数据
复制代码 代码示例:
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用在接下来的查询中。
查询语句：
复制代码 代码示例:
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的语句：
复制代码 代码示例:
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之类(既然分组集对应的值都是唯一的)，但也写成跟下面的一样的，有木有？
复制代码 代码示例:
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
);
跑完这条查询估计要从破晓到夕阳沉入大地。我不知道它要跑多久，因为我没打算让它无休止地跑下去。
