having必须紧跟group by之后，不能替代where；它仅用于筛选分组后的聚合结果，而where负责分组前的行级过滤，二者执行时机、作用对象和允许使用的表达式均不同。
HAVING 必须跟在 GROUP BY 后面，不能替代 WHERE
很多人写 HAVING 时直接接在 SELECT 后，结果报错：ERROR: HAVING clause without GROUP BY。这是因为 HAVING 只能作用于分组后的聚合结果，不是行级过滤——那是 WHERE 的事。
典型错误写法：SELECT user_id, COUNT(*) FROM logs HAVING COUNT(*) > 5;（缺少 GROUP BY）
正确结构必须是：SELECT ... FROM ... GROUP BY ... HAVING ...
-
WHERE过滤原始行（在分组前），支持字段名、普通条件，如WHERE status = 'active' -
HAVING过滤分组后结果（在GROUP BY之后），可引用聚合函数，如HAVING COUNT(*) >= 3 - 如果既要行级过滤又要分组后过滤，两个子句可以共存：
WHERE created_at > '2024-01-01' GROUP BY user_id HAVING SUM(amount) > 100
HAVING 中不能用 SELECT 别名，得重复表达式
写 SELECT AVG(score) AS avg_score FROM exams GROUP BY class HAVING avg_score > 85; 会失败（MySQL 5.7+ 默认严格模式下报错：Unknown column 'avg_score' in 'having clause'）。HAVING 解析早于别名绑定，不认 AS 定义的别名。
必须写成：HAVING AVG(score) > 85，或者用完整表达式（比如 HAVING (SUM(score)/COUNT(*)) > 85）。
- PostgreSQL 允许在
HAVING中用别名，但 MySQL、SQL Server、SQLite 不支持——跨数据库迁移时尤其容易踩坑 - 别名只在
SELECT和ORDER BY中安全可用；WHERE、HAVING、GROUP BY都不行 - 复杂表达式重复写两遍易出错，建议先确认逻辑，再复制粘贴，别靠记忆改
NULL 值在 HAVING 中的处理很隐蔽
聚合函数遇到全 NULL 分组时，COUNT(*) 返回 0，但 COUNT(col)、SUM(col)、AVG(col) 返回 NULL。这时候 HAVING SUM(revenue) > 1000 会把该分组整个跳过——因为 NULL > 1000 结果是 UNKNOWN，不满足真值条件。
这不是 bug，是 SQL 三值逻辑的正常表现，但常被忽略。
- 要包含 NULL 聚合结果的分组，显式判断：
HAVING SUM(revenue) > 1000 OR SUM(revenue) IS NULL - 更常见需求是“排除 NULL”，这时用
HAVING SUM(revenue) IS NOT NULL AND SUM(revenue) > 1000 -
COUNT(*)永远非 NULL，适合做存在性判断，比如HAVING COUNT(*) >= 1总是成立，但没意义；真正有用的是HAVING COUNT(col) > 0确认某列有非空值
性能上，HAVING 无法利用索引，慎用于大数据量分组
HAVING 是在内存中对已分组结果做筛选，不像 WHERE 可以借助索引快速排除行。如果 GROUP BY 产生几万组，再用 HAVING 扫一遍，效率明显下降。
- 优先把能下推的条件放进
WHERE：比如想查“近30天下单超5次的用户”，写成WHERE order_time >= NOW() - INTERVAL 30 DAY，而不是让HAVING COUNT(*) > 5处理全部历史数据 - 避免在
HAVING里调用函数，如HAVING YEAR(created_at) = 2024，这会让引擎无法使用created_at索引 - 如果分组键基数极高（如按 UUID 分组），
GROUP BY + HAVING很可能成为瓶颈，考虑是否真需要聚合，或改用应用层二次过滤
实际用的时候，先问自己一句：这个条件是筛原始行，还是筛分组桶？筛桶才轮到 HAVING 出场；一上来就写 HAVING，八成是逻辑没理清。
