having不能省略group by，因为其作用对象是分组后的“组”，没有group by就不存在分组，也就无组可筛；即使只需全局聚合（如count(*)>1000），也须显式写group by()以确保跨数据库兼容性。
HAVING 是唯一能直接筛分组结果的子句，必须跟在 GROUP BY 后面，且只能引用分组字段、聚合函数或它们的别名。其他方式（如把条件塞进 WHERE）会报错或逻辑错误。
为什么 HAVING 不能省略 GROUP BY？
HAVING 的作用对象是“组”，没有 GROUP BY 就没有组——哪怕你只想要一个全局聚合值（比如 COUNT(*) > 1000），也得显式写 GROUP BY ()。MySQL 允许隐式单一分组，但 PostgreSQL 会直接报错：column "xxx" must appear in the GROUP BY clause。跨库迁移时，漏掉 GROUP BY () 是常见翻车点。
HAVING 能用哪些字段？哪些绝对不行？
能安全用的只有三类：
-
GROUP BY列本身（如user_id、dept） - 聚合函数（如
COUNT(*)、AVG(salary)、MAX(created_at)） -
SELECT中定义的别名（如cnt、avg_sal），但注意：SQLite 和旧版 MySQL 不支持
绝对不能用的：
- 未出现在
GROUP BY中的原始字段（如status、created_at），否则报Unknown column 'status' in 'having clause' - 未被聚合包裹的非分组列（
SELECT dept, user_name FROM employees GROUP BY dept HAVING AVG(salary) > 10000在ONLY_FULL_GROUP_BY模式下必败）
什么时候必须放弃 HAVING，改用子查询或 CTE？
HAVING 只做“组内判断”，一旦涉及跨组逻辑，它就无能为力：
- 需要和全局均值比较：比如“销售额高于所有部门平均值的部门” → 必须用子查询算出均值再比
- 需要否定逻辑：比如“买过 A 类商品但从未买过 B 类商品的用户” → 得靠
NOT EXISTS或LEFT JOIN ... IS NULL - 同一分组结果要多次复用（既取 Top 3，又算标准差）→
WITHCTE 更清晰、更少重复计算
子查询还有一条铁律：MySQL 和 PostgreSQL 都强制要求派生表加别名，漏掉 AS t 会直接报 Every derived table must have its own alias。
性能与顺序陷阱：为什么 WHERE 必须在 GROUP BY 前？
想查“2024 年订单数超 5 的客户”，正确顺序是：WHERE order_date >= '2024-01-01' → GROUP BY customer_id → HAVING COUNT(*) > 5。如果把时间条件错塞进 HAVING，数据库会先对全表分组（可能生成上千个空组），再逐个检查，白白消耗 CPU 和内存。更糟的是，HAVING order_date >= '2024-01-01' 还会因字段未分组而直接报错。
真正容易被忽略的，是 HAVING 后的 ORDER BY：它排的是聚合后的结果集，不是原始行；所以 ORDER BY COUNT(*) DESC 没问题，但 ORDER BY created_at 就大概率失败——除非你把它也放进 GROUP BY 或用子查询兜底。
