where不能直接使用聚合函数，因其执行顺序在group by之前，此时count(*)等值尚未计算；必须用having（配合group by）、子查询或窗口函数替代。
因为WHERE子句执行时，聚合函数的值根本还没算出来——它发生在GROUP BY之前，数据库连“按哪列分组”都还没做，更别说COUNT(*)或SUM(amount)了。
WHERE阶段聚合值压根不存在
SQL真实执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：
-
WHERE看到的只是原始表的一行行数据，没有任何分组信息 - 你写
WHERE COUNT(*) > 5，PostgreSQL 直接报aggregate functions are not allowed in WHERE，MySQL 8.0+ 报Invalid use of group function - 哪怕表只有一行，
WHERE COUNT(*) = 1也非法——不是数值错，是语法阶段就被拦下 - 旧版 MySQL（如 5.6）可能不报错，但会把整张表当一个隐式组来算，导致逻辑失控：例如
WHERE COUNT(*) > 1实际等价于“只要总行数 ≥ 2 就返回全表”
HAVING才是聚合后过滤的唯一合法位置
HAVING专为聚合结果设计，但它必须和 GROUP BY 成对出现：
- 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错（语义模糊：对谁分组？） -
HAVING COUNT(*) >= 3合法；HAVING cnt >= 3（引用SELECT中定义的别名）在 MySQL/PostgreSQL 中可行，但 SQLite 或旧版 MySQL 可能不认，建议优先复写表达式 - 性能上，
WHERE status = 'paid'这种条件必须放WHERE——硬塞进HAVING会让数据库先对百万行分组再扔掉 90% 的组，极易 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 会报错 - 窗口函数方式（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），内存暴涨、查询超时几乎是必然的。
