在SQL里，聚合函数和子查询各自都不难，但把它们组合起来做多层统计时，不少语句会卡在作用域限制上。典型错误是：外层查询已经按客户分组算出订单数量，内层还想基于这个订单数量再做一次平均。比如下面这种写法，看起来合理，却无法通过数据库的语义检查。
聚合结果为什么不能被子查询直接引用
出现这种限制，根源在于SQL的逻辑执行顺序。标准SQL的处理顺序大致是FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY，聚合函数只有在GROUP BY分组完成后才会产生确定的值。子查询如果出现在SELECT或HAVING中，它的作用域仍然属于外层查询的同一层，不能看到外层分组后才生成的聚合列。换句话说，COUNT(*)这样的聚合结果不是一个普通的列引用，而是在分组阶段动态计算出来的，内层查询无法把它当作一个已存在的列来使用。
举一个典型错误示例：假设orders表包含customer_id和amount字段，想查出每个客户的订单数，并同时计算所有客户订单数的平均值。如果写出下面这种语句，就会遇到列无法绑定或未知列的错误。
SELECT customer_id,
COUNT(*) AS order_cnt,
(SELECT AVG(order_cnt)
FROM orders o2
WHERE o2.customer_id = o.customer_id) AS avg_cnt
FROM orders o
GROUP BY customer_id;
这里子查询中的order_cnt是外层SELECT列表里的别名，又是聚合结果，数据库在解析子查询时无法引用它。即便把这个别名改成COUNT(*)，也会遇到聚合函数不能嵌套的限制。理解这一点之后，就需要换一种方式把聚合结果先固定下来，再参与后续比较。
通过HAVING子句配合派生表实现聚合结果引用
第一种可行方案是把聚合结果先算出来，放到一个派生表中。派生表会被当作一个普通的表来使用，里面的聚合列就变成了普通列，外层查询就可以通过HAVING子句进行过滤。这种思路本质上是在同一个查询中创建了两层结构：内层负责聚合，外层负责继续使用聚合结果。
例如要筛选出订单数量高于全体客户平均订单数量的客户，可以先在派生表中按客户分组统计订单数，然后在HAVING子句中用一个独立的子查询计算全体客户的平均订单数。SQL可以写成：
SELECT customer_id, COUNT(*) AS order_cnt
FROM orders
GROUP BY customer_id
HAVING COUNT(*) > (
SELECT AVG(order_cnt)
FROM (
SELECT customer_id, COUNT(*) AS order_cnt
FROM orders
GROUP BY customer_id
) AS t2
);
这个写法虽然能正常运行，但有一个明显的缺点：内层派生表t2重复执行了一次按客户分组和计数，等于orders表被扫描了两遍。当数据量较大时，这种重复扫描会造成不必要的I/O和计算开销。为了让逻辑更清晰，也可以先把派生表提取出来作为一个公共表表达式，但重复计算仍然存在。
如果数据库支持窗口函数，后续会介绍更高效的替代方式。但在不支持窗口函数的旧版本数据库中，这种派生表加HAVING的写法是最直接的实现路径。它把聚合结果实体化成了一个结果集，绕过了内层查询不能引用外层聚合列的语法限制。
通过HAVING子句配合相关子查询实现条件比较
第二种思路是在HAVING子句中使用相关子查询，但子查询只引用外层的普通分组列，而不是聚合列。这种模式适合拿外层分组的聚合结果与另一个相关范围的聚合结果进行比较。
假设有两张表：customers表包含customer_id和city字段，orders表包含customer_id和amount字段。现在要找出总消费金额高于所在城市平均客户消费金额的客户。这里外层的聚合结果是每个客户的SUM(amount)，比较对象是客户所在城市的平均客户消费总额。SQL可以这样写：
SELECT c.customer_id, c.city, SUM(o.amount) AS total_amount
FROM customers c
JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.city
HAVING SUM(o.amount) > (
SELECT AVG(city_total)
FROM (
SELECT c2.city, c2.customer_id, SUM(o2.amount) AS city_total
FROM customers c2
JOIN orders o2 ON o2.customer_id = c2.customer_id
GROUP BY c2.city, c2.customer_id
) AS city_totals
WHERE city_totals.city = c.city
);
这个例子中，子查询没有直接引用外层的SUM(o.amount)，而是引用了外层的普通列c.city。外层聚合结果放在HAVING左侧参与比较，内层子查询则负责计算该城市的平均客户消费金额。这种方式的优点是符合SQL标准，几乎所有关系型数据库都支持。但缺点也明显：外层每一组都会触发一次相关子查询的执行，如果客户数量很多，城市分组很多，整体性能会受到影响。
为了减少相关子查询的重复计算，可以先按城市、客户两个维度聚合，把结果存成临时表或派生表，再在外层进行过滤。这样至少可以避免多次JOIN orders表。但在只写一条SQL的场景下，上述写法已经可以满足功能需求。
窗口函数替代方案：直接在同一层引用聚合结果
如果数据库支持窗口函数，问题会简单很多。窗口函数允许在不分组的情况下，对聚合结果进行计算，而且可以在同一层直接引用它们。例如要筛选出订单数高于全体客户平均订单数的客户，可以这样写：
SELECT customer_id, order_cnt
FROM (
SELECT customer_id,
COUNT(*) AS order_cnt,
AVG(COUNT(*)) OVER () AS avg_order_cnt
FROM orders
GROUP BY customer_id
) AS t
WHERE order_cnt > avg_order_cnt;
这里AVG(COUNT(*)) OVER ()的含义是：在已经按customer_id分组的基础上，对所有分组的COUNT(*)结果求平均。OVER ()表示这个窗口函数在所有分组结果上计算，不需要再写子查询。与外层查询相同，avg_order_cnt成为普通列，可以放在WHERE中直接过滤。
对比派生表方案，窗口函数方案只扫描一次orders表，执行计划通常更优。在PostgreSQL、MySQL 8.0、SQL Server、Oracle等现代数据库中都可以使用。不过要注意，窗口函数的计算发生在GROUP BY之后，因此不能直接在同一个SELECT里同时引用窗口函数结果和原始行数据，需要套一层子查询来过滤，这也是上面代码外层包了FROM ( ... ) AS t的原因。
执行计划与性能注意事项
三种方案在性能上差异明显。派生表方案会执行两次分组，订单表可能被扫描两遍；相关子查询方案在外层每组执行一次子查询，如果分组数量较大，开销会线性增长；窗口函数方案通常只需要一次扫描和一次排序，属于性能最好的选择。实际开发中，如果数据量不大，哪种写法都可以；一旦涉及百万级以上的行，建议优先使用窗口函数。
另外还要注意HAVING子句本身的功能边界。HAVING是在分组后过滤，适合对聚合结果做条件判断；WHERE则是在分组前过滤原始行。不要试图在WHERE中直接使用聚合函数，例如WHERE COUNT(*) > 5在多数数据库中会直接报错。把聚合条件放在HAVING中才是正确用法。配合子查询时，子查询如果放在HAVING里，它的返回结果必须是单值，否则会抛出“子查询返回多行”的错误。
最后总结一下完整思路：外层聚合结果不能被子查询直接引用，是因为作用域和聚合计算的时机不对。想引用聚合结果，可以把它转成普通列，比如用派生表或窗口函数；也可以在HAVING左侧使用聚合结果，子查询只引用外层普通列。三种写法各有适用场景，掌握之后就能更灵活地处理多层统计需求。