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，导致子查询变成笛卡尔积式扫描
