SUM(SUM(x)) OVER()合法，因内层SUM是GROUP BY阶段聚合，外层SUM是作用于聚合结果集的窗口函数；而AVG(SUM(x))等嵌套非法，因标准禁止聚合函数直接包裹窗口函数。
SUM 和 OVER 能一起用，但不能随意嵌套；关键不是“能不能写”，而是“执行顺序是否允许”——聚合函数在 GROUP BY 阶段完成，窗口函数在之后阶段运行，两者作用层级不同。
为什么 SUM(SUM(x)) OVER() 看似矛盾却合法？
这个写法在 PostgreSQL、SQL Server、Oracle、Doris 和 MySQL 8.0+ 中都有效，但容易误解为“聚合套窗口”。实际语义是：
- 内层
SUM(amount)是标准聚合，必须配合GROUP BY department使用，产出每部门一行 - 外层
SUM(...) OVER()是窗口函数，作用对象是上一步的聚合结果集（即分组后的几行），对它们再求和 - 因为没写
PARTITION BY，所以SUM(SUM(amount)) OVER()返回的是单个标量值（公司总销售额），自动广播到每一行
错误写法如 AVG(SUM(x)) 或 COUNT(SUM(x)) OVER() 会直接报错：语法不允许聚合函数包裹窗口函数，也不允许反向嵌套。
已 GROUP BY 后还想加占比列，别硬套 OVER()
如果你的查询已经执行了 GROUP BY，结果只有 department 和 dept_total 两列，此时再写 SUM(dept_total) OVER() 不会得到总数，而是返回当前行的 dept_total（因为窗口默认只有一行，没分区也没跨行）。
正确做法是显式拉取总数并广播：
WITH dept_sum AS ( SELECT department, SUM(amount) AS dept_total FROM sales GROUP BY department ), total AS ( SELECT SUM(dept_total) AS all_total FROM dept_sum ) SELECT d.department, d.dept_total, ROUND(d.dept_total * 1.0 / t.all_total, 4) AS ratio FROM dept_sum d CROSS JOIN total t;
-
CROSS JOIN安全且意图明确：把单行总数复制到每一行 - 避免用子查询或标量子查询反复调用
(SELECT SUM(...))，性能更稳 - 乘
1.0是防止整数除法截断（尤其在 PostgreSQL/MySQL 中）
想同时看明细 + 汇总 + 排名？先开窗，再 GROUP BY 可能反而错
典型需求如：“每个销售员的总业绩、占公司比、在部门内排名”——这时不该先按人聚合，而应从明细行出发，用窗口函数逐行计算：
SELECT salesperson_id, department, SUM(amount) OVER (PARTITION BY salesperson_id) AS personal_total, SUM(amount) OVER () AS company_total, ROUND(SUM(amount) OVER (PARTITION BY salesperson_id) * 100.0 / SUM(amount) OVER (), 2) AS percentage, RANK() OVER (PARTITION BY department ORDER BY SUM(amount) OVER (PARTITION BY salesperson_id) DESC) AS dept_rank FROM sales_records;
- 所有
SUM(...) OVER都基于原始明细行，不丢失粒度 -
RANK()必须跟ORDER BY，否则报错window function requires an ORDER BY clause - 注意
PARTITION BY department和内部SUM(...) OVER (PARTITION BY salesperson_id)的嵌套逻辑：窗口函数可多层嵌套，只要不违反执行顺序
容易被忽略的兼容性细节
MySQL 8.0+ 支持 SUM(SUM(x)) OVER()，但低版本不支持；PostgreSQL 和 SQL Server 更早支持。实际写之前要确认：
- 数据库版本是否达标（特别是生产环境可能仍是 MySQL 5.7）
- 字段是否含
NULL：聚合函数默认忽略NULL，但COALESCE(SUM(x), 0)更稳妥 - 排序稳定性：若
ORDER BY字段有重复值，RANK()和DENSE_RANK()行为不同，业务上必须明确选哪个
最常出问题的不是语法，而是误以为“写了 OVER 就能跨过 GROUP BY 阶段”——窗口函数永远作用于它能看到的那一批行，而那批行早已被 GROUP BY 塑形过了。
