WHERE阶段无法使用COUNT()等聚合函数，因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，聚合值在WHERE时还未计算；HAVING才是聚合后过滤的合法位置，但必须与GROUP BY配合；子查询或窗口函数派生表可绕过此限制。
WHERE阶段根本没算出COUNT()的值
不是数据库“不支持”，而是执行顺序决定了它不可能支持。SQL真实执行流程是 FROM → WHERE → GROUP BY → HAVING → SELECT。你在WHERE里写COUNT(*) > 5，相当于让数据库在还没分组、更没统计之前，就拿一个“不存在的数字”做判断——它连“对哪几行计数”都不知道，自然直接报错。
常见错误现象：
-
MySQL报Invalid use of group function -
PostgreSQL报aggregate functions are not allowed in WHERE -
SQL Server报Cannot perform an aggregate function on an expression containing an aggregate
哪怕表只有一行，WHERE COUNT(*) = 1 也非法——问题不在数值，而在这个值此刻根本未生成。
HAVING才是聚合后过滤的唯一合法位置
HAVING专为聚合结果设计，但它必须和GROUP BY成对出现。它运行在分组完成、各组COUNT()、AVG()都已算好之后，这时用聚合函数才有意义。
实操要点：
- 没写
GROUP BY却用HAVING，MySQL 5.7+默认报错（语义模糊：对谁分组？） -
HAVING COUNT(*) >= 3合法；HAVING cnt >= 3（引用SELECT中别名）在MySQL/PostgreSQL中可用，但SQLite或旧版可能不认，建议复写表达式 - 像
status = 'paid'这种行级条件，必须放WHERE——塞进HAVING会让数据库先对全部百万行分组再扔掉90%，极易OOM
想绕开GROUP BY又用聚合逻辑？子查询最稳
如果业务只要“订单数≥3的用户ID”，但不想结果里带COUNT(*)列，硬套GROUP BY + HAVING反而冗余。子查询是最兼容、最可控的解法。
正确写法：
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会报错 - 外层
WHERE能用t.cnt，是因为此时cnt已是普通列，不是聚合函数 - 相比窗口函数或标量子查询，子查询在所有主流数据库（包括
SQLite）上都可用，且优化器通常能较好处理
窗口函数能“广播”聚合值，但不能直出WHERE
COUNT(*) OVER (PARTITION BY user_id)可以把每个用户的订单数算出来，并“附着”到每一行上。但它本身不能出现在WHERE里——执行顺序没变，窗口函数仍受同一套规则约束。
必须先生成，再引用：
SELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3;
关键细节：
- 窗口函数必须出现在
SELECT或派生表中，才能被外层WHERE使用 -
MySQL 8.0+、PostgreSQL、SQL Server支持；MySQL 5.7及更早版本不支持 - 大表慎用：若
PARTITION BY键基数极高（比如千万级user_id），窗口计算本身开销不小
HAVING不只是语法报错，它会让数据库多做大量无用聚合——尤其当分组键基数高时，内存暴涨、查询超时甚至OOM，往往就在写错那一行代码之后。 
