where不能使用聚合函数，因其执行在group by和聚合计算之前；having才是聚合后过滤的合法位置，但必须配合group by使用。
因为 WHERE 子句在 SQL 执行顺序中位于 GROUP BY 和聚合计算之前，此时 COUNT()、SUM() 等函数根本还没运行，数据库连值都没有，自然无法参与比较。
SQL执行顺序决定了WHERE看不到聚合结果
真实执行流程是：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依然非法——问题不在数值对不对，而在“这个值此刻不存在”
HAVING 是唯一合法使用聚合函数做条件的位置
HAVING 是专为聚合后过滤设计的子句，但它必须配合 GROUP BY 使用：
- 没有
GROUP BY却写HAVING，MySQL 5.7+ 默认报错（语义模糊：对谁分组？） -
HAVING COUNT(*) >= 3是合法的，因为此时每组的计数已算完 -
HAVING cnt >= 3（引用SELECT中的别名）在 MySQL/PostgreSQL 中可行，但 SQLite 或旧版 MySQL 可能不认，建议优先复写表达式 - 性能上，
WHERE能大幅减少输入行数，HAVING只能筛组——所以像status = 'paid'这种条件必须放WHERE，硬塞进HAVING会让数据库先对百万行分组再扔掉 90% 的组
没分组也要用聚合逻辑？得绕开执行顺序限制
如果业务只要“订单数 ≥ 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 不只是语法问题，它会让数据库多做大量无用聚合计算——尤其当分组键基数高（比如千万级用户），内存暴增、查询超时、甚至 OOM。更隐蔽的是：你以为加了时间过滤，其实漏写了 WHERE order_date >= '2024-01-01'，只靠 HAVING COUNT(*) > 10，查出来的“高频用户”可能全是十年前的老数据。
