HAVING必须紧跟GROUP BY之后，用于过滤分组后的聚合结果；单独使用会报错，因HAVING作用对象是分组产生的每组聚合值而非原始行，且条件中只能用聚合函数或GROUP BY字段。
HAVING 必须跟在 GROUP BY 后面，不能单独用
直接写 HAVING 而不写 GROUP BY 会报错，比如 MySQL 报 ERROR 1140: In aggregated query without GROUP BY。因为 HAVING 的作用对象是分组后的结果集，不是原始行——它过滤的是 GROUP BY 产生的每组聚合值，不是单条记录。
常见错误写法：SELECT user_id, COUNT(*) FROM orders HAVING COUNT(*) > 5 —— 缺少 GROUP BY user_id，数据库不知道“每组”指什么。
- 正确顺序永远是：
GROUP BY→HAVING→ORDER BY（可选） -
HAVING条件中允许使用聚合函数（COUNT()、SUM()、AVG()等），而WHERE不允许 - 如果只想要全局聚合结果（如“所有订单总数 > 100”），不用
GROUP BY和HAVING，直接用WHERE或子查询更合适
WHERE 和 HAVING 的执行时机与字段限制不同
WHERE 在分组前过滤行，HAVING 在分组后过滤组。这意味着：能写在 WHERE 里的字段，不一定能在 HAVING 里直接用；反之亦然。
例如，想查“每个用户下单金额总和超过 1000 且下单时间在 2024 年之后的用户”，必须拆开写：WHERE 过滤时间（行级），HAVING 过滤金额总和（组级）：
SELECT user_id, SUM(amount) AS total FROM orders WHERE order_time > '2024-01-01' GROUP BY user_id HAVING SUM(amount) > 1000;
-
WHERE中不能用SUM(amount)、COUNT(*)等聚合结果 -
HAVING中不能直接引用未出现在GROUP BY或聚合函数中的非聚合列（如WHERE中可用的order_id，在HAVING里不可直接用） - 某些数据库（如 PostgreSQL）要求
SELECT列表中的非聚合字段必须出现在GROUP BY中，否则报错；MySQL 默认宽松，但开启ONLY_FULL_GROUP_BY后行为一致
HAVING 中用别名会出错，得重复表达式
很多人习惯在 SELECT 中用别名（如 SUM(amount) AS total），然后在 HAVING 里写 HAVING total > 1000 —— 大部分数据库（包括 MySQL 5.7+、PostgreSQL、SQL Server）不支持这种写法，会报 Unknown column 'total' 或类似错误。
- 必须写完整表达式：
HAVING SUM(amount) > 1000，不能用total - MySQL 8.0+ 在某些模式下允许别名，但跨库兼容性差，不建议依赖
- 如果表达式复杂（如
ROUND(AVG(price) * 1.1, 2)），重复写两遍易出错，可考虑用子查询或 CTE 封装，但要注意性能影响
NULL 值在 HAVING 中的行为容易被忽略
聚合函数对 NULL 的处理是隐式的：COUNT(*) 计数所有行，COUNT(col) 忽略 col 为 NULL 的行，SUM()、AVG() 也自动跳过 NULL。但如果你在 HAVING 中写 HAVING COUNT(*) = 0，这永远不成立——因为没行就不会产生分组，根本不会进入 HAVING 判断。
- 想查“没有任何订单的用户”，不能靠
HAVING COUNT(*) = 0，得用LEFT JOIN+WHERE orders.user_id IS NULL -
HAVING COUNT(col) = 0是有效的，表示该组中col全为 NULL 或无非空值 - 比较时注意 NULL 安全：比如
HAVING SUM(amount) >= 1000 OR SUM(amount) IS NULL要显式判断，>、=等操作符遇到 NULL 一律返回 UNKNOWN，不满足条件
实际用的时候，最常卡住的地方不是语法，而是混淆了“过滤行”和“过滤组”的边界，以及低估了 NULL 在聚合路径中的消失和重现方式。
