HAVING必须跟在GROUP BY后，仅能引用GROUP BY列或聚合函数；NULL值导致条件为unknown而静默丢组；复杂逻辑应改用CTE或子查询。
HAVING 必须跟在 GROUP BY 后，否则直接报错
PostgreSQL 16 不允许 HAVING 独立出现。写成 SELECT dept, COUNT(*) FROM employees HAVING COUNT(*) > 1 会触发错误：SQLSTATE[42000]: Syntax error or access rule violation: 7 ERROR: column "employees.dept" must appear in the GROUP BY clause or be used in an aggregate function。根本原因是：没有 GROUP BY，数据库就不知道“按什么分组”，也就无从定义“哪个组满足 HAVING 条件”。必须先明确分组维度，HAVING 才有作用域。
多字段逻辑判断只能基于 GROUP BY 列或聚合结果
HAVING 的条件表达式里能用的只有两类东西：一是出现在 GROUP BY 子句中的列（如 dept, location），二是聚合函数（如 COUNT(*), AVG(salary)）。不能引用未分组的单行字段，比如 WHERE status = 'active' 放进 HAVING 就会报错：column "status" must appear in the GROUP BY clause or be used in an aggregate function。常见误用场景包括：
- 想筛出“部门平均薪资 > 10000 且人数 HAVING AVG(salary) > 10000 AND COUNT(*) —— 这是合法的
- 想筛出“部门在北京且平均薪资 > 10000”，却写成
HAVING location = '北京' AND AVG(salary) > 10000—— 这要求location必须在GROUP BY中，否则失败 - 想用
HAVING过滤某字段的非空比例，得写成HAVING COUNT(email) * 1.0 / COUNT(*) > 0.9，不能用email IS NOT NULL直接判断
NULL 值会让 HAVING 条件静默失效
PostgreSQL 16 默认按 SQL 标准处理三值逻辑（true/false/unknown）。如果某组的 AVG(salary) 是 NULL（比如该部门所有员工 salary 全为 NULL），那么 HAVING AVG(salary) > 10000 的结果是 unknown，整组被丢弃——不报错，也不返回，容易漏数据。稳妥做法是显式补全判断：
- 用
HAVING AVG(salary) IS NOT NULL AND AVG(salary) > 10000 - 用
HAVING COUNT(salary) > 0 AND AVG(salary) > 10000（语义更清晰，强调“有有效薪资记录”） - 避免依赖
COUNT(*) > 0，因为它恒为真（空组根本不会进入 HAVING 阶段）
复杂多字段逻辑建议改用子查询或 CTE
当需要跨组比较、引用窗口函数、或做“本组均值 > 全局均值”这类操作时，HAVING 无能为力。例如以下写法在 PostgreSQL 16 中非法：
SELECT dept, AVG(salary) FROM employees GROUP BY dept HAVING AVG(salary) > AVG(salary); -- 错误：不能在同一层多次聚合
正确解法是用 CTE 预算全局基准：
WITH global_avg AS ( SELECT AVG(salary) AS g_avg FROM employees ) SELECT e.dept, AVG(e.salary) AS dept_avg FROM employees e CROSS JOIN global_avg g GROUP BY e.dept, g.g_avg HAVING AVG(e.salary) > g.g_avg;
这种结构把“全局聚合”和“分组聚合”拆到不同作用域，既可读又可控。别硬扛，CTE 不是炫技，是绕过 HAVING 语法边界的必要手段。
