WHERE不能使用聚合函数，因为其执行在GROUP BY之前，此时COUNT(*)等值尚未计算；HAVING才是筛选聚合结果的正确位置，且必须与GROUP BY配合使用。
因为WHERE执行时聚合值根本不存在，不是语法限制太死，而是数据库连“算什么”都不知道。
WHERE阶段压根看不到COUNT(*)或SUM()
SQL真实执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：
-
WHERE只能访问原始表里的一行行数据，每行都是孤立的，没有“组”的概念 -
COUNT(*)、SUM(amount)这些值要等到GROUP BY完成后才开始计算，WHERE阶段它们连内存地址都没有 - 哪怕你写
WHERE COUNT(*) = 1，哪怕表真只有一行，也会在语法解析阶段被拒绝——不是结果错，是表达式非法 - PostgreSQL 报
aggregate functions are not allowed in WHERE，MySQL 报Invalid use of group function，SQL Server 报类似错误
HAVING才是聚合条件的唯一合法位置
HAVING 是专为聚合后筛选设计的，但它必须和 GROUP BY 成对出现：
- 正确写法：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) >= 3 - 别名在
HAVING里可用（如HAVING cnt >= 3），但 SQLite 或旧版 MySQL 可能不认，建议复写表达式 - 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错，标准 SQL 不允许 - 把本该放
WHERE的行级条件（比如status = 'paid'）硬塞进HAVING，会导致全量数据先分组再筛，极易 OOM 或超时
想绕开GROUP BY又得用聚合逻辑？换写法
如果业务只要“订单数 ≥ 3 的用户 ID”，但不想最终结果带 COUNT(*) 列，就得避开执行顺序限制：
- 子查询方式（兼容性最好）：
SELECT user_id FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t WHERE t.cnt >= 3—— 注意内层必须有别名t - 窗口函数方式（MySQL 8.0+/PostgreSQL）：
SELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3—— 窗口函数不能直出WHERE，必须先生成列 - 标量子查询：
WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3，但大表易变 N+1，性能通常较差
最常被忽略的一点是：错把聚合条件塞进 HAVING 不只是语法问题，它会让数据库多做大量无用聚合计算——尤其当分组键基数高（比如按 user_id 分上百万组），内存暴涨、查询超时往往就发生在这一念之间。
