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