SQL聚合函数不能在WHERE子句中使用，因执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE阶段尚未分组且聚合值未计算；应改用HAVING（需配合GROUP BY）、子查询或窗口函数。
WHERE子句里写或一定会报错，不是数据库不支持，而是执行阶段根本没到算聚合值的时候。
WHERE阶段看不到分组结果
SQL真实执行顺序是
→
→
→
→
。这意味着：
处理的是原始行，每行都独立存在；
这种函数依赖“哪些行属于同一组”，但此时连
都还没跑，压根没有“组”的概念。
你写
，PostgreSQL 直接抛
MySQL 会报
，哪怕表只有一行也拦下——不是值不对，是语法阶段就拒绝
别指望“先算一遍总数再过滤”：引擎不会为
临时补一个隐式分组，那会彻底破坏语义一致性
HAVING才是聚合筛选的唯一合法位置
必须跟在
之后，它作用的对象是“已分好组、且各组聚合值已算完”的中间结果集。
正确写法：先
，再
可以引用
里的别名（如
），但SQLite或旧版MySQL可能不认，建议直接复写
没写
却用了
？MySQL 5.7+ 默认报错，因为“对谁分组”语义模糊，标准SQL不允许
想绕过GROUP BY又用聚合条件？用子查询或窗口函数
如果业务只要“订单数≥3的用户ID”，但不想在最终结果里出现
列，硬套
+
会多出一列，这时得换路子。
子查询方式：
，注意子查询必须带别名（如
）否则MySQL 8.0+/PostgreSQL报错
窗口函数方式（MySQL 8.0+/PostgreSQL/SQL Server）：
；注意
不能直接放外层
，必须先在派生表里生成
别在
里塞标量子查询（如
），大表上性能极差，每行都触发一次子查询
最容易被忽略的是性能陷阱：把本该下推到
的条件（比如
）错放
，会导致数据库先对全部百万行分组计算，再删掉90%的组——内存爆掉或超时往往就在这一步。
COUNT()SUM()FROMWHEREGROUP BYHAVINGSELECTWHERECOUNT(*)GROUP BYWHERE COUNT(*) > 5ERROR: aggregate function calls cannot contain column referencesInvalid use of group functionWHEREHAVINGGROUP BYGROUP BY user_idHAVING COUNT(*) >= 3HAVINGSELECTHAVING total_cnt > 10HAVING COUNT(*) > 10GROUP BYHAVINGCOUNT(*)GROUP BYHAVINGWHERE user_id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) >= 3)tSELECT user_id FROM (SELECT user_id, COUNT(*) OVER (PARTITION BY user_id) AS cnt FROM orders) t WHERE cnt >= 3COUNT() OVERWHEREWHEREWHERE (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) > 2WHEREstatus = 'paid'HAVING