HAVING不能直接使用子查询，必须通过窗口函数（如AVG(salary) OVER()）或派生表获取全局聚合值后比较；WHERE与HAVING混用时需确保基准一致，避免逻辑矛盾。
HAVING 不能直接写子查询，必须用聚合函数包裹
很多人写 HAVING salary > (SELECT AVG(salary) FROM employees) 会报错，因为 HAVING 只能对 GROUP BY 后的聚合结果做条件判断，而子查询返回的是标量值，和当前分组上下文不匹配。SQL 引擎无法把全局平均值自动“广播”到每个分组中参与比较。
正确做法是：先算出全局平均值（比如用窗口函数或派生表），再让每组拿自己的聚合值去比。常见可落地的方案有两个：
- 用
AVG() OVER()窗口函数，在同一查询中同时拿到分组均值和全局均值 - 把子查询放到
FROM子句里作为临时表（派生表），然后JOIN或直接引用
用窗口函数在 HAVING 中安全比较（推荐）
这是最简洁、性能通常也更好的方式，尤其适合 MySQL 8.0+、PostgreSQL、SQL Server、Oracle 等支持窗口函数的数据库。核心思路是：把全局平均值“拉平”到每一行，再按部门分组后取最大/平均等聚合值，最后在 HAVING 中比较。
SELECT dept, AVG(salary) AS avg_dept_salary FROM employees GROUP BY dept HAVING AVG(salary) > AVG(salary) OVER();
注意：AVG(salary) OVER() 是整张表的平均值，它在 GROUP BY 后仍可用，且不破坏分组逻辑。但别写成 HAVING AVG(salary) > (SELECT AVG(salary) FROM employees) —— 大多数数据库会报错“不能在 HAVING 中使用非 GROUP BY 列的子查询”。
用派生表避免窗口函数兼容性问题
如果用的是 MySQL 5.7 或旧版 PostgreSQL，不支持窗口函数，就得把全局平均值先算出来，放进一个临时结果集里。关键点是：不能在 HAVING 里直接引用子查询，但可以在 FROM 里把它当一张表用。
SELECT t1.dept, AVG(t1.salary) AS avg_dept_salary FROM employees t1 CROSS JOIN (SELECT AVG(salary) AS global_avg FROM employees) t2 GROUP BY t1.dept HAVING AVG(t1.salary) > t2.global_avg;
这里 CROSS JOIN 是安全的，因为子查询只返回一行一列；t2.global_avg 在 HAVING 中是合法引用。别漏掉 GROUP BY，否则 AVG(t1.salary) 和 t2.global_avg 类型不匹配，会触发错误。
WHERE 和 HAVING 混用时的过滤顺序陷阱
有人想先用 WHERE 过滤掉低薪员工，再查“高于全局平均”的部门，结果发现结果偏差很大——这是因为 WHERE 会先筛数据，导致全局平均值变小，后续比较基准就错了。
例如：
SELECT dept, AVG(salary) FROM employees WHERE salary > 5000 -- 先筛人，全局平均被拉高 GROUP BY dept HAVING AVG(salary) > (SELECT AVG(salary) FROM employees); -- 这里的子查询仍是原表平均！
这种写法逻辑矛盾：子查询没加 WHERE 条件，但前面又筛了数据。正确做法是统一基准——要么全用原始表算平均，要么把 WHERE 条件也同步进子查询里：
- 保持基准一致：子查询也要加同样
WHERE条件 - 或者干脆去掉
WHERE，改用HAVING控制分组粒度
真正容易被忽略的是：HAVING 的筛选对象永远是分组后的聚合值，不是原始行；而子查询默认脱离当前查询上下文——这两者不天然对齐，必须显式桥接。
