AVG(SUM(x))一定报错，因SQL标准禁止嵌套聚合函数，解析器在语法分析阶段即拒绝；所有主流数据库均报“cannot nest aggregate functions”错误，本质是SUM输出标量而AVG需输入一组值。
AVG(SUM(x)) 为什么一定报错
因为 SQL 解析器在语法分析阶段就拒绝这种写法，不是数据或括号问题，而是标准硬性限制。所有主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、Oracle）都会报类似 aggregate function calls cannot be nested 或 Invalid use of aggregate function 的错误。
根本原因是语义模糊：引擎无法判断你是想对“每组的 SUM(x)”求平均，还是先全表加总再除个数。更底层看，SUM(x) 在 GROUP BY 后输出的是标量（每组一个值），而 AVG() 需要一组值作为输入——它没地方拿到“一组”。
-
COUNT(DISTINCT col)是唯一例外，它是单函数语法糖，不是真嵌套 -
AVG(SUM(x)) OVER()同样非法，窗口函数不改变这一限制 - 哪怕加了
GROUP BY，同一 SELECT 层级仍不允许嵌套
子查询实现两层聚合时最容易踩的坑
派生表是最通用解法，但语法细节错一点就失败。
- 子查询必须带别名，例如
AS t；漏掉会报subquery in FROM must have an alias - 内层
SELECT必须显式写出字段并命名，比如SUM(sales) AS dept_total；外层只能引用t.dept_total，不能写t.sales - 外层不能加
GROUP BY，否则又变成分组聚合，达不到“对聚合结果再聚合”的目的 - 内层
GROUP BY缺失或漏列（如非聚合字段未包含），会导致逻辑偏差甚至报错
CTE 和窗口函数的适用边界在哪
CTE 可读性好，窗口函数适合保留明细，但它们不是万能替代。
- CTE 要求括号严格闭合，
WITH dept_summary AS (SELECT ... GROUP BY dept_id)少一个)就报syntax error, expect RPAREN - CTE 名不能和真实表重名，否则 PostgreSQL 可能优先解析为基表
- 窗口函数不能绕过嵌套限制：
AVG(SUM(x)) OVER()依然非法；正确写法是先SUM(x) OVER(PARTITION BY dept_id)，再AVG() OVER() - 窗口函数生成的是追加列，不改变行数；若目标是单值汇总（如“所有部门总和的均值”），仍得用子查询或 CTE
外层 AVG(AVG(x)) 看似可行，实际藏着偏差
用 AVG(avg_per_group) 替代 AVG(sum_per_group) 表面能跑通，但业务含义可能歪掉。
比如各区域订单数差异极大：A 区 1000 单、B 区 10 单。算“区域均值的均值”会把 A 和 B 平等对待，掩盖了总量分布；而“区域总和的均值”才反映真实权重。这种偏差不会报错，但结果不可信。
真正容易被忽略的是：你没意识到自己正在做加权还是简单平均，也没检查分组粒度是否匹配业务口径。
