WHERE中不能用COUNT()或SUM()，因为SQL执行顺序为FROM→WHERE→GROUP BY→HAVING→SELECT，WHERE在分组和聚合计算前执行，此时聚合值尚未生成，数据库在语法解析阶段即报错。
WHERE里写COUNT()或SUM()一定报错，不是写法不对，而是执行顺序根本不允许——它压根还没算出来。
为什么WHERE里用COUNT(*)会直接报错
SQL真实执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT。WHERE阶段只看到原始表的每一行，COUNT(*)、SUM(amount)这些值要等GROUP BY跑完才生成。数据库在语法解析阶段就拒绝这种写法：
- PostgreSQL 报
aggregate functions are not allowed in WHERE - MySQL 8.0+ 报
Invalid use of group function - Oracle 报
ORA-00934: group function is not allowed here
旧版MySQL（如5.6）可能不报错，但会把整张表当一个隐式组来算，WHERE COUNT(*) > 1实际等价于“只要总行数≥2就返回全表”，逻辑完全失控。
HAVING必须配合GROUP BY才能用
HAVING是唯一合法放聚合函数的地方，但它不是WHERE的替代品——它是分组后的过滤器，必须和GROUP BY成对出现：
- 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错（语义模糊：对谁分组？） -
HAVING COUNT(*) >= 3合法；HAVING cnt >= 3（引用SELECT别名）在MySQL/PostgreSQL中可行，但SQLite或旧版MySQL可能不认，建议复写表达式 - 行级条件（如
status = 'paid'）必须放WHERE，否则数据库先对百万行分组再扔掉90%，极易OOM
正确写法示例：
SELECT user_id, COUNT(*) AS cnt<br>FROM orders<br>WHERE status = 'paid' -- ✅ 提前筛行<br>GROUP BY user_id<br>HAVING COUNT(*) >= 3; -- ✅ 分组后筛组
不想要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报错 - 窗口函数方式（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，必须先在派生表或SELECT中生成 - 标量子查询（慎用）：
WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3，大表时易变N+1，性能差
最容易被忽略的性能陷阱
把本该下推的条件留在HAVING，不只是语法问题，更是内存和时间的双重浪费。比如user_id IN (1001,1002)这种条件，硬塞进HAVING会让数据库先对全部用户分组、计算每组订单数，再丢掉99%的组。尤其当分组键基数高（如按user_id分上百万组）时，错用HAVING可能直接触发OOM或超时。真正关键的不是“怎么让语句跑通”，而是“让哪部分数据尽早被剪掉”。
