WHERE不能过滤COUNT()结果，因为WHERE在聚合前执行而COUNT()等聚合函数只在GROUP BY后生成，故WHERE中使用聚合函数会报错；正确做法是用HAVING在聚合后筛选。

为什么 WHERE 不能过滤 COUNT() 结果

因为 WHERE 在聚合前执行，而 COUNT()、SUM() 这类聚合函数的结果只在 GROUP BY 之后才存在。你写 WHERE COUNT(*) > 5，SQL 引擎直接报错：ERROR: aggregate functions are not allowed in WHERE。

常见错误现象：把本该放 HAVING 的条件硬塞进 WHERE，结果要么报错，要么逻辑错——比如想查“订单数超 10 的用户”，却只查出单条记录（因为 WHERE 先筛了某一行，再聚合）。

• HAVING 是唯一能在聚合后对分组结果做条件筛选的子句
• HAVING 必须跟在 GROUP BY 后面；没 GROUP BY 时，它作用于整个结果集（相当于单一分组）
• 支持所有聚合函数和分组字段，也支持非聚合字段——但仅限于 SELECT 中出现过的、或明确出现在 GROUP BY 中的列

HAVING 和子查询嵌套时的执行顺序陷阱

当 HAVING 条件里嵌套子查询（比如查“平均订单金额高于全站平均值的品类”），容易误以为子查询先跑完、再拿结果去比。实际上，多数数据库（PostgreSQL、MySQL 8.0+、SQL Server）会为每一组重新执行一次子查询——不是算一次全局均值然后复用。

性能影响明显：1000 个分组，子查询就跑 1000 次。如果子查询本身又含聚合或 JOIN，响应时间可能从毫秒级跳到秒级。

• 优先用窗口函数替代：比如 AVG(amount) OVER() 可一次性算出全局均值，避免重复执行
• 若必须用子查询，把它提到 FROM 子句中作为派生表（CTE 或内联视图），确保只计算一次
• MySQL 5.7 及更早版本不支持在 HAVING 中引用子查询别名，会报 Unknown column 'x' in 'having clause'，得改写成重复子查询或提前物化

GROUP BY 字段缺失导致 HAVING 行为异常

当你写了 HAVING COUNT(*) > 1 却忘了写 GROUP BY，不同数据库表现不一：PostgreSQL 直接拒绝执行；MySQL（严格模式关闭时）会把整张表当作一个组，返回至多一行；SQL Server 则可能报错 Column 'xxx' is invalid in the HAVING clause。

更隐蔽的问题是：SELECT 中有非聚合字段（如 user_name），但 GROUP BY 漏掉了它。这时 HAVING 虽能通过语法检查，但 user_name 的值是任意选取的（MySQL 5.7+ 默认拒绝，PostgreSQL 强制要求出现在 GROUP BY 中）。

• 务必确认 GROUP BY 包含所有非聚合字段，否则结果不可靠
• 开启 SQL 标准模式（如 PostgreSQL 的 sql_mode=ONLY_FULL_GROUP_BY）可提前暴露这类问题
• 用 SELECT * + HAVING 几乎必然出错，因为星号展开后字段大概率没被 GROUP BY 覆盖

子查询返回多行时 HAVING 报错的典型场景

HAVING 中的子查询如果返回多于一行，几乎所有数据库都会报错，例如：HAVING SUM(price) > (SELECT category_id FROM category WHERE active = true)。错误信息通常是：ERROR: more than one row returned by a subquery used as an expression。

这不是语法问题，而是语义冲突：标量比较（>）要求右边是一个单一数值，但子查询给了一个列表。

• 加 LIMIT 1 或 TOP 1 是危险解法——结果不可控，且掩盖了设计意图
• 正确做法是明确业务含义：如果是“大于任一分类 ID”，改用 > ANY(...)；如果是“大于所有分类 ID”，用 > ALL(...)
• 更常见的是误把关联条件写漏，比如少写了 WHERE t.category_id = c.id，导致子查询变成笛卡尔积式扫描

实际写复杂聚合过滤时，最易被忽略的是子查询的执行粒度——它到底按什么范围跑、跑几次、返回几行。这些细节不显眼，但直接决定结果对不对、快不快。