having用于group by后过滤聚合结果，因where在分组前执行、无法使用count()或sum()等未计算的聚合函数，故where count(*)>5会报错；having可引用分组列、聚合函数及部分版本支持的别名。
HAVING 是分组后过滤的直接、高效且语义清晰的选择；嵌套子查询仅在 HAVING 无法满足逻辑（比如跨组比较、需要多次聚合）时才应考虑。
为什么不能用 WHERE 过滤 COUNT() 或 SUM() 结果
WHERE 在 GROUP BY 之前执行，此时 COUNT()、SUM() 等聚合函数尚未计算，字段值也未归并成组——所以写 WHERE COUNT(*) > 5 会直接报错，常见错误信息是 Invalid use of group function 或 Unknown column 'xxx' in 'where clause'。
典型误用场景：
- 想查“订单数超 10 的客户”，却写了
SELECT customer_id, COUNT(*) FROM orders WHERE COUNT(*) > 10 GROUP BY customer_id→ 语法错误 - 用
SELECT * FROM sales GROUP BY region HAVING total = SUM(amount)，但total是别名，某些旧版 MySQL 不支持在 HAVING 中直接引用别名（需重写为SUM(amount) > 10000）
HAVING 的正确写法与限制
HAVING 必须紧跟在 GROUP BY 之后（或隐式单一分组时），它能引用：
-
GROUP BY中出现的列（如salesman） - 任意聚合函数（如
COUNT(*)、AVG(price)、MAX(created_at)） - SELECT 中定义的列别名（MySQL 5.7+、PostgreSQL、SQL Server 支持；但 SQLite 和部分老版本 MySQL 不支持）
- 常量和表达式（如
HAVING COUNT(*) * 1.2 > 100）
注意：如果开了 SQL 标准模式（如 MySQL 的 sql_mode=ONLY_FULL_GROUP_BY），SELECT * + GROUP BY + HAVING 几乎必然失败，因为星号展开的字段大概率没被 GROUP BY 覆盖。
什么情况下必须用嵌套子查询替代 HAVING
HAVING 只能做“组内判断”，无法做“组间比较”或“依赖外部上下文”的过滤。这时才需要子查询，常见于：
- 查“销售额高于平均销售额的部门”：需先算出全局平均，再和每组比较 →
HAVING SUM(amount) > (SELECT AVG(total) FROM (SELECT SUM(amount) AS total FROM sales GROUP BY dept) t) - 查“购买过 A 类商品但从未买过 B 类商品的用户”：需两个聚合结果做集合差，HAVING 无法表达否定逻辑 → 得用
NOT EXISTS或LEFT JOIN ... IS NULL - 想对同一张表做两次不同维度的分组（如先按月统计，再筛出其中“连续 3 个月达标”的记录）→ HAVING 无状态，必须用 CTE 或派生表
性能提示：子查询若放在 HAVING 内部（如 HAVING x > (SELECT ...)），可能被重复执行；应提至 FROM 子句作为派生表或 CTE，确保只计算一次。
容易被忽略的兼容性细节
不同数据库对 HAVING 的宽松程度差异较大：
- MySQL 5.7 默认允许
HAVING引用非GROUP BY列（只要它在 SELECT 中出现），但这违反 SQL 标准，升级到 8.0 后默认开启ONLY_FULL_GROUP_BY就会报错 - PostgreSQL 严格要求：HAVING 中所有非聚合字段必须出现在
GROUP BY列表中 - SQL Server 支持在 HAVING 中用列别名，但 Oracle 不支持（得写完整表达式）
最稳妥的做法是：把 HAVING 条件里所有非聚合字段都显式列入 GROUP BY，聚合表达式不依赖别名——这样写的 SQL 在各主流数据库上迁移成本最低。
