where不能使用聚合函数，因其执行在group by和聚合计算之前；having才是过滤聚合结果的正确位置，必须与group by配合使用。
因为WHERE执行时，COUNT()、SUM()这些值根本还没算出来——数据库连结果都没有，自然不能拿它过滤。
WHERE阶段聚合值还不存在
SQL真实执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT。这意味着：WHERE看到的只是原始表里的一行行数据，没分组、没统计、没“组内有多少条”这种概念。
-
WHERE COUNT(*) > 5会直接报错，PostgreSQL 提示aggregate function calls cannot contain column references，MySQL 8.0+ 报Invalid use of group function - 哪怕表只有一行，也拦下——不是值不对，是语法阶段就拒绝
- 别指望用别名绕过：
SELECT COUNT(*) AS cnt后写WHERE cnt > 5依然非法，WHERE压根看不到SELECT里的别名
HAVING才是放聚合条件的唯一位置
HAVING 在 GROUP BY 之后运行，此时每组的 COUNT(*)、AVG(price) 都已算好，可以直接用。
codex-orchestration
下载
一款AI工具，主要用于Codex 通用编排：利用 `update_plan` 与后台 PTY 终端并行运行 `codex exec` 工作进程，适合需要提升相关任务效率的用户。
- 必须和
GROUP BY成对出现；没写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 往往就在这一念之间。
