where不能使用聚合函数，因其在group by和聚合计算前执行，此时count()等值尚未生成；having才用于聚合后过滤，必须与group by配合使用。
因为WHERE在分组和聚合计算之前执行，此时COUNT()、SUM()这些函数根本还没算出来，数据库连值都没有，自然不能拿它过滤。
WHERE执行时，聚合值还不存在
SQL的实际执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着WHERE看到的只是原始表的一行行数据，没分组、没统计——COUNT(*)要等GROUP BY跑完才得出结果。
- 写
WHERE COUNT(*) > 5会直接报错，比如 PostgreSQL 提示aggregate functions are not allowed in WHERE，MySQL 8.0+ 报Invalid use of group function - 即使某些旧版 MySQL（如 5.6）不报错，它也会把整张表当一个隐式组来算，
WHERE COUNT(*) > 1实际变成“只要表里有 2 行以上就返回所有行”，逻辑完全失控 - 别指望用别名绕过：哪怕你写了
SELECT COUNT(*) AS cnt，WHERE cnt > 5依然非法——WHERE看不到SELECT里的别名
HAVING才是放聚合条件的唯一位置
HAVING专为聚合后过滤设计，它在GROUP BY之后运行，每组的COUNT()、AVG()都已算好，可以直接用。
- 必须和
GROUP BY成对出现；没写GROUP BY却用HAVING，MySQL 5.7+ 默认拒绝（除非关掉ONLY_FULL_GROUP_BY） - 支持用别名，比如
HAVING cnt >= 3（MySQL/PostgreSQL），但为兼容性，更推荐直接写HAVING COUNT(*) >= 3 - 别把能下推的条件塞进
HAVING：比如user_id IN (1001, 1002)这种行级筛选，放进WHERE能大幅减少分组输入量，硬塞HAVING等于让数据库白算上百万组再扔掉
想在非分组查询里用聚合逻辑？得换写法
如果业务就是“查订单数 ≥ 3 的用户”，又不想显式写GROUP BY，就得绕开执行顺序限制：
- 用子查询：内层聚合，外层用
WHERE比较结果，例如SELECT user_id FROM (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) t WHERE t.cnt >= 3 - 用窗口函数（MySQL 8.0+/PostgreSQL）：
COUNT(*) OVER (PARTITION BY user_id)给每行附上本用户的订单数，再在外层WHERE中使用——注意窗口函数本身不能直出WHERE，必须先出现在SELECT或派生表里 - 标量子查询也行：
WHERE (SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) >= 3，但性能通常较差，尤其大表时容易变 N+1
最常被忽略的一点是：错把条件放HAVING不只是语法问题，它会让数据库多做大量无用聚合计算，内存暴涨、查询超时、甚至OOM——尤其当分组键基数高（比如千万级user_id）时，这个代价非常真实。
