WHERE中不能用COUNT()等聚合函数，因为WHERE在分组前执行，而聚合值尚未计算；必须用HAVING在GROUP BY后过滤聚合结果，否则报错且性能极差。
WHERE 里写 COUNT() 为什么会报错
因为 SQL 引擎在执行 WHERE 子句时，还没开始分组、也没算出聚合值——COUNT()、SUM()、AVG() 这些函数依赖于“已分组后的行集合”，而 WHERE 是在分组前过滤原始行的。所以你写 WHERE COUNT(*) > 10，数据库会直接报类似 ERROR: aggregate functions are not allowed in WHERE 的错误。
常见错误现象：
- PostgreSQL 报
ERROR: aggregate function calls cannot contain column references - MySQL 8.0+ 默认 SQL 模式下报
Invalid use of group function - 即使语义上“想筛出订单数超 5 的用户”，硬塞
COUNT(user_id) > 5到WHERE也一定失败
HAVING 才是放聚合条件的正确位置
HAVING 是唯一能接聚合函数的地方，它在 GROUP BY 之后执行，此时每组的 COUNT()、MAX() 等结果已经算出来了。
实操建议：
- 先写
GROUP BY，再决定哪些聚合结果要过滤 → 这部分逻辑全丢进HAVING -
HAVING可以引用SELECT中的别名（如 MySQL、PostgreSQL 支持HAVING total_cnt > 10），但为兼容性，建议直接复写表达式，比如HAVING COUNT(*) > 10 - 不要在
HAVING里重复写WHERE已做过的事，比如WHERE status = 'active'应该前置，避免对无效行做分组和聚合
示例：查至少下过 3 单的用户 ID
SELECT user_id, COUNT(*) AS cnt FROM orders WHERE created_at >= '2024-01-01' -- 先筛时间范围，减少分组数据量 GROUP BY user_id HAVING COUNT(*) >= 3;
WHERE 和 HAVING 的性能差异很实际
把本该放 WHERE 的条件错放 HAVING，不只是语法错，还会明显拖慢查询。
原因：
-
WHERE在分组前过滤，输入给GROUP BY的行数更少 → 聚合计算快，内存占用低 -
HAVING是对所有分组结果再过滤，意味着数据库得先把全部分组算完，哪怕其中 90% 的组最后被HAVING删掉 - 尤其在大表 + 高基数分组列（如按
user_id分上百万组）时，错用HAVING可能导致 OOM 或超时
典型反模式：
-- ❌ 错误：把可下推的过滤留在 HAVING GROUP BY user_id HAVING user_id IN (1001, 1002, 1003) AND COUNT(*) > 1 <p>-- ✅ 正确：user_id 条件放进 WHERE，让引擎提前剪枝 WHERE user_id IN (1001, 1002, 1003) GROUP BY user_id HAVING COUNT(*) > 1
ORDER BY 和 SELECT 里也能用聚合函数，但逻辑不同
SELECT 和 ORDER BY 中允许聚合函数，是因为它们在 GROUP BY 和 HAVING 之后执行，此时聚合值已就绪。
注意点：
-
ORDER BY中的聚合表达式，不能依赖未出现在GROUP BY中的非聚合列（否则 MySQL 会报错，PostgreSQL 严格要求 functional dependency） - 如果用了
SELECT *+GROUP BY a，ORDER BY b（b 不在 GROUP BY 里）大概率失败，不是语法问题，而是语义不确定 - 某些旧版 MySQL 允许这种写法（
sql_mode不含ONLY_FULL_GROUP_BY），但结果不可靠，切换数据库或升级后容易崩
真正安全的写法始终是：GROUP BY 列 = SELECT 中所有非聚合列 = ORDER BY 中所有非聚合列。
聚合函数的位置不是语法随意性问题，而是执行阶段强约束。很多人调通了就不管，但线上查千万级订单表时，一个 WHERE 和 HAVING 的错位，可能让响应时间从 200ms 变成 12s —— 而且这个瓶颈在开发机上根本压不出来。
