having只能用于分组后的聚合结果筛选，因其执行时机在group by之后，作用对象是各分组的聚合值（如count(*)、avg(price)），不能用于筛选未分组的全局聚合结果。
HAVING 只能用于分组后的聚合结果筛选
HAVING 的语义和执行时机决定了它**不能筛选“未分组”的聚合结果**。SQL 执行顺序是 WHERE → GROUP BY → HAVING → SELECT → ORDER BY，HAVING 发生在分组之后，它的过滤对象只能是每个分组产生的聚合值（如 COUNT(*)、AVG(price)），而不是原始行或全局聚合结果。
想筛全局聚合结果？用子查询或 CTE
比如你想知道“所有订单总金额是否超过 10000”，这本质是单行全局聚合，不是按某列分组后的多行聚合——这时 HAVING 直接失效：
SELECT SUM(amount) FROM orders HAVING SUM(amount) > 10000; -- ❌ 语法错误：无 GROUP BY 却用 HAVING
正确做法是把聚合结果当作一行数据来过滤：
- 用子查询 +
WHERE：SELECT total FROM (SELECT SUM(amount) AS total FROM orders) t WHERE total > 10000;
- 或用 CTE（更清晰）：
WITH agg AS (SELECT SUM(amount) AS total FROM orders) SELECT * FROM agg WHERE total > 10000;
- 如果只是做条件判断（如在应用中触发逻辑），多数数据库支持直接
SELECT CASE WHEN SUM(amount) > 10000 THEN 'yes' ELSE 'no' END FROM orders，无需HAVING。
常见误用：加了 GROUP BY 但逻辑上不需要分组
有人为“凑出 HAVING”而写 GROUP BY () 或 GROUP BY 1=1，这在部分数据库（如 PostgreSQL）中可行，但属于非常规写法：
SELECT SUM(amount) FROM orders GROUP BY () HAVING SUM(amount) > 10000; -- ✅ PostgreSQL 允许，但可读性差、移植性差
问题在于：
-
GROUP BY ()是 SQL 标准扩展，并非所有数据库支持（MySQL 8.0+ 不支持，SQL Server 报错）； - 语义模糊：读者第一反应是“这里应该有分组维度”，反而增加理解成本；
- 优化器可能无法有效处理空分组，性能不如子查询稳定。
真正需要 HAVING 的典型场景
只有当你明确要“对每个分组的聚合值做条件过滤”时，HAVING 才不可替代。例如：
- 查每个部门平均薪资 > 15000 的部门：
SELECT dept, AVG(salary) FROM employees GROUP BY dept HAVING AVG(salary) > 15000;
- 排除订单数少于 5 的客户：
SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*)
- 注意：
WHERE不能用聚合函数，所以WHERE COUNT(*) > 5是语法错误；HAVING是唯一能写聚合条件的地方——但前提是前面有GROUP BY。
混淆点往往在“以为 HAVING 是‘更高级的 WHERE’”，其实它只是 GROUP BY 的配套过滤器。没分组，就别硬套 HAVING。
