where不能使用聚合函数，因为其执行在group by和聚合计算之前；having才是过滤聚合结果的正确位置，且必须配合group by使用。
因为 WHERE 子句执行时，COUNT()、SUM()、MAX() 这些值根本还没算出来——数据库连“每组有多少行”都不知道，自然没法拿它过滤。
WHERE 阶段压根看不到聚合结果
SQL 的真实执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：WHERE 只能访问原始表里的一行行数据，没分组、没统计、没“组内总和”这种概念。
-
WHERE COUNT(*) > 5会直接报错，PostgreSQL 提示aggregate functions are not allowed in WHERE，MySQL 报Invalid use of group function - 哪怕表只有一行，也拦下——不是值不对，是语法阶段就拒绝
- 别指望用别名绕过：
SELECT COUNT(*) AS cnt后写WHERE cnt > 5依然非法，WHERE压根看不到SELECT里的别名
HAVING 是唯一合法位置，但必须配 GROUP BY
HAVING 在 GROUP BY 之后运行，此时每组的 COUNT(*)、AVG(price) 都已算好，可以直接用。
- 没写
GROUP BY却用HAVING，MySQL 5.7+ 默认报错（语义不明确） -
HAVING COUNT(*) >= 3合法，HAVING cnt >= 3在 MySQL/PostgreSQL 中可用，但为兼容 SQLite 或旧版，建议复写表达式 - 能下推的条件别塞进
HAVING：比如status = 'paid'这种行级筛选，放进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 不只是语法问题，它会让数据库多做大量无用聚合计算——尤其当分组键基数高（比如按 user_id 分上百万组），内存暴涨、查询超时、甚至 OOM 往往就在这一念之间。
