会，绝大多数数据库不允许在HAVING子句中直接使用窗口函数，因其执行顺序在聚合之后且HAVING不支持分析层计算；正确做法是用CTE或子查询先物化窗口结果，再通过WHERE或HAVING引用。
HAVING 里直接用窗口函数会报错吗
会，绝大多数数据库（包括 PostgreSQL、SQL Server、MySQL 8.0+）都不允许在 HAVING 子句中直接使用窗口函数，比如 AVG(score) OVER() 或 COUNT(*) OVER(PARTITION BY dept)。错误提示通常是 WINDOW function is not allowed in HAVING clause 或类似语法拒绝信息。
根本原因是执行顺序：GROUP BY → 聚合计算 → HAVING 过滤，而窗口函数属于“分析层”，必须在聚合之后、但又不能嵌套在 HAVING 这种组级过滤子句里——它没被设计成参与分组裁决。
- 别尝试写
HAVING AVG(score) > AVG(score) OVER()，这在 PostgreSQL 15 前不合法；2026 年部分新版本虽有实验性支持，但文档未正式纳入标准 -
OVER()出现在HAVING中，会被解析器当作语法错误，而非运行时逻辑错误 - 即使某次“侥幸通过”，也极可能因优化器重写导致结果不可复现，不建议在生产环境试探
正确做法：把窗口函数提前到子查询或 CTE 中
真正可靠且跨库兼容的路径，是把窗口计算挪到 GROUP BY 之前或之外，让其结果变成普通列，再交给 HAVING 或 WHERE 处理。
例如查“部门平均分高于全表平均分的部门”：
WITH dept_stats AS (
SELECT
dept,
AVG(score) AS dept_avg,
AVG(score) OVER() AS global_avg
FROM scores
GROUP BY dept
)
SELECT dept, dept_avg
FROM dept_stats
WHERE dept_avg > global_avg;
- 这里用
GROUP BY dept先算出每个部门均值，再用OVER()把全局均值广播为每行一列 - 外层不用
HAVING，改用WHERE——因为此时dept_avg和global_avg都已是标量列，不是聚合上下文 - 如果非要用
HAVING（比如后续还要加COUNT(*) > 5），就把WHERE换成HAVING，但注意：该查询已无原始行，HAVING在这里等价于WHERE
为什么不用 HAVING + 子查询？
很多人想绕开窗口函数，改用 HAVING COUNT(*) > (SELECT AVG(cnt) FROM (...))，这条路在多数引擎上走不通。
原因很实在：
-
HAVING中的子查询若不关联当前分组（即非相关子查询），MySQL 8.0+ 会拒绝，PostgreSQL 直接报错subquery in HAVING is not allowed - 即使旧版 MySQL 容忍，子查询也会被反复执行（每组一次），性能崩盘；且语义模糊：你真想要“每组都重算一次全局均值”，还是“只算一次然后广播”？
- CTE 或临时表能物化子查询结果，但本质上仍是把“基准值”提前准备好——和窗口函数思路一致，只是写法更啰嗦
所以，与其折腾子查询嵌套，不如一步到位用 CTE + 窗口函数，逻辑干净、执行计划可预测。
容易被忽略的 NULL 和类型对齐问题
窗口函数输出的列和聚合列一旦参与比较，NULL 和精度就容易翻车。
-
AVG(score) OVER()若源数据全为NULL，结果是NULL；NULL > 80判定为UNKNOWN，整行被过滤掉——这不是 bug，是三值逻辑，但常被误认为“没数据” - 如果
SELECT里写了ROUND(AVG(score), 2)，而WHERE里用dept_avg > 85.5，浮点舍入误差可能导致边界值漏判 - MySQL 和 PostgreSQL 对
DECIMAL与FLOAT的隐式转换行为不同，建议显式CAST(global_avg AS DECIMAL(10,2))
复杂过滤真正难的从来不是语法，而是你是否清楚每一列在每一层的值域、空值行为和精度来源。
