HAVING不能引用外层聚合结果，因其作用域仅限本层GROUP BY分组，执行顺序中它位于外层聚合计算之前；正确做法是重写聚合表达式或用CTE/派生表分层处理。
HAVING 不能直接引用外部查询的聚合结果，这是很多写嵌套查询时踩坑的起点。如果你试图在子查询里用 HAVING 去过滤外层的 SUM()、COUNT() 等结果，SQL 会报错——因为 HAVING 只作用于它所在层级的 GROUP BY 分组，不跨作用域，也不感知外层聚合别名。
为什么 HAVING 无法访问外层聚合值
SQL 执行顺序决定了作用域边界：WHERE → GROUP BY → HAVING → SELECT → ORDER BY。每个 HAVING 只能引用当前 SELECT 中定义的列、本层 GROUP BY 字段，以及本层聚合函数（如 COUNT(*)）。外层查询的聚合结果（比如 AS total_sales）在子查询执行时根本还没计算出来。
- 错误示例（语法非法）：
SELECT * FROM (SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING total > 1000) t—— 这里total是别名，HAVING不认 - 正确写法必须把聚合表达式原样重写：
HAVING SUM(amount) > 1000，不能用别名 - 如果外层有复杂聚合（比如窗口函数或嵌套聚合），那更不能在内层
HAVING中引用
想“引用外层聚合”？实际要的是分层过滤逻辑
所谓“引用外层聚合”，往往真实需求是：先按某维度汇总，再基于该汇总结果做二次筛选或关联。这时应拆成两步，而不是硬塞进一个 HAVING：
- 用外层查询做主聚合（带
GROUP BY和必要HAVING） - 把外层结果当临时表（派生表或 CTE），在内层用
WHERE过滤——此时聚合值已物化为列，可直接引用 - 例如：找出“平均订单金额 > 200 且总下单次数 > 5”的客户
WITH customer_stats AS (
SELECT
customer_id,
AVG(order_amount) AS avg_order,
COUNT(*) AS order_count
FROM orders
GROUP BY customer_id
)
SELECT customer_id, avg_order, order_count
FROM customer_stats
WHERE avg_order > 200 AND order_count > 5;WHERE + 子查询 vs HAVING：别混淆时机
容易误以为 WHERE 在子查询里也能用聚合，但其实不行——除非子查询本身带 GROUP BY。关键区别在于：
- 子查询若无
GROUP BY，则不能用COUNT()、SUM()等聚合函数（会报错“无效使用聚合函数”） - 子查询若有
GROUP BY，那它的HAVING只管自己的分组，和外层无关 - 真正能“跨层引用”的，只有标量子查询（返回单值），例如：
WHERE total_sales > (SELECT AVG(total_sales) FROM ...)
最常被忽略的一点：HAVING 条件里写的聚合表达式，必须和 SELECT 或 GROUP BY 中出现的聚合完全一致（包括括号、参数顺序），否则某些数据库（如 MySQL 严格模式）会拒绝执行。别图省事缩写或改别名。
