HAVING中不能使用RANK() OVER()等窗口函数，因为HAVING在GROUP BY之后、SELECT之前执行，仅处理聚合结果，而窗口函数属于SELECT阶段计算，SQL标准禁止其出现在HAVING中，必须通过CTE或子查询先固化结果再筛选。
为什么HAVING里写RANK() OVER()会报错
因为HAVING只处理GROUP BY之后的聚合结果，而窗口函数（如RANK()、ROW_NUMBER()、SUM() OVER()）作用于行级数据，且语义上依赖分组后的完整行集——但它本身不是聚合函数，也不参与分组计算。SQL标准明确禁止在HAVING中出现窗口函数表达式，执行时直接报window functions are not allowed in HAVING。
HAVING和窗口函数的执行阶段根本错位
HAVING发生在GROUP BY之后、SELECT之前，它看到的只有聚合值（如COUNT(*)、AVG(salary)），而窗口函数实际是在SELECT阶段才被计算，此时HAVING早已结束。你写HAVING RANK() OVER (PARTITION BY dept ORDER BY salary) = 1，数据库连这个表达式都拒绝解析——不是算出来不对，是压根不许写。
- HAVING过滤的是“组”，窗口函数输出的是“行”
- 即使你先GROUP BY再试图对结果做窗口排名，也必须把聚合结果作为新数据源，再套一层查询
- 没有引擎能绕过这个逻辑顺序，PostgreSQL、MySQL 8.0+、SQL Server 全部一致
想基于分组结果做窗口筛选，只能用CTE或子查询提前固化
典型做法是：内层GROUP BY得到聚合结果（比如每个部门的平均薪资），外层把它当普通表，再加窗口函数广播、排序、编号，最后用WHERE过滤。不能指望HAVING来承接这一步。
- 错误写法：
HAVING AVG(score) > AVG(score) OVER()→ 语法直接拒 - 正确路径：
WITH dept_avg AS (SELECT dept, AVG(score) AS avg_score FROM scores GROUP BY dept) SELECT * FROM dept_avg WHERE avg_score > (SELECT AVG(avg_score) FROM dept_avg) - 如果要跨组比较（如“高于全局均值的部门”），
OVER()必须放在CTE内层，让窗口结果成为可筛选列 - 别在CTE里写
SELECT *，尤其当原始表字段多时，会拖慢中间结果传输
ORDER BY在OVER里漏写，会让窗口结果不可靠
比如ROW_NUMBER() OVER (PARTITION BY dept_id)没写ORDER BY，数据库可能按存储顺序编号，每次执行结果不同。这在CTE或子查询中尤其危险——你以为rn=1是最高薪，其实只是随机一行。
-
PARTITION BY和ORDER BY在窗口定义中缺一不可 - ORDER BY字段必须有确定性（避免用
id但无索引，或created_at精度不足） - 若需稳定结果又无天然排序依据，可补
ORDER BY salary DESC, id ASC兜底
真正卡住多数人的，不是不会写窗口函数，而是误以为HAVING能“接住”它。只要记住：HAVING只认GROUP BY产出的聚合列，窗口函数产出的任何东西，都得先落地成普通列，才能进WHERE——而这个落地动作，必须靠显式嵌套完成。
