having不能直接写在子查询的where后面，必须封装为独立子查询或cte；sql标准规定having仅可用于顶层select或完整独立查询，否则报“syntax error at or near 'having'”错误。
HAVING 不能直接写在子查询的 WHERE 后面
你写 WHERE customer_id IN (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5)，几乎所有主流数据库（PostgreSQL、MySQL 8.0+、SQL Server）都会报错：ERROR: syntax error at or near "HAVING"。因为 SQL 标准明确规定：HAVING 只能出现在顶层 SELECT 或独立的完整查询中，不能嵌在子查询的 WHERE 里——它不是“过滤行”的工具，而是“过滤分组”的子句。
必须把 GROUP BY + HAVING 封装成独立子查询或 CTE
正确做法是让聚合逻辑自成一句完整查询，再把它当数据源用：
- 用派生表（带
AS t的子查询）：SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5) AS t); - 用 CTE 更清晰，尤其当聚合逻辑复杂（比如多字段分组、要复用结果）：
WITH active_customers AS (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) >= 3 AND SUM(amount) > 1000) SELECT o.* FROM orders o INNER JOIN active_customers a ON o.customer_id = a.customer_id; - MySQL 5.7 及更早不支持 CTE，只能用第一种写法；PostgreSQL 和 SQL Server 对 CTE 的物化支持更好，执行计划更可控。
HAVING 条件里不能引用别名，也不能用聚合函数以外的字段
比如下面这句会失败：
-
HAVING order_cnt > 5——order_cnt是外层SELECT中定义的别名，HAVING看不到它，必须写成HAVING COUNT(*) > 5； -
HAVING customer_name = 'Alice'—— 如果customer_name没出现在GROUP BY列表里，PostgreSQL 直接拒绝，MySQL（非严格模式）可能返回任意值，结果不可靠； -
SELECT * FROM orders GROUP BY customer_id HAVING COUNT(*) > 5—— 几乎必然出错，因为*展开后包含未被GROUP BY覆盖的字段（如order_date），违反 SQL 标准。
子查询里用聚合结果做比较时，注意性能陷阱
如果在 HAVING 里嵌套子查询（比如 HAVING AVG(amount) > (SELECT AVG(amount) FROM orders)），多数数据库会对每一组重新执行一次子查询——1000 个分组，子查询就跑 1000 次。
- 优先用窗口函数替代：
AVG(amount) OVER()一次性算出全局均值； - 若必须用子查询，把它提到
FROM子句中作为派生表或 CTE，确保只计算一次； - MySQL 5.7 不支持在
HAVING中引用子查询别名，会报Unknown column 'x' in 'having clause'，得重复写子查询或提前物化。
真正容易被忽略的是执行顺序：WHERE → GROUP BY → HAVING → SELECT。这意味着你在 HAVING 里能用的，只有 GROUP BY 列和聚合函数结果；而 WHERE 里根本不能出现 COUNT() 这类东西——它还没诞生呢。
