AVG(SUM(x))在SQL中非法，因标准禁止聚合函数嵌套，语义不明确；须用子查询或CTE实现两层聚合，窗口函数无法替代二次聚合。
AVG(SUM(x)) 这类写法在任何主流 SQL 引擎里都会直接报错，不是配置问题，也不是版本差异，而是 SQL 标准本身禁止聚合函数嵌套。
为什么 AVG(SUM(x)) 会触发 AnalysisException
错误信息通常是 “aggregate function cannot contain aggregate parameters” 或 “cannot nest aggregate functions”。这不是执行阶段的问题，而是在语法解析（analysis）阶段就被拒绝——引擎根本不会尝试执行它。因为语义不明确：你到底想对“每组的 SUM 结果”求平均，还是先全表 SUM 再除个数？SQL 要求每个聚合函数的作用域必须清晰，嵌套会让分组维度和计算顺序产生冲突。
注意：COUNT(DISTINCT col) 看似嵌套，实为单函数语法糖，不在此列；但 SUM(AVG(y))、MAX(MIN(z)) 全部非法。
用子查询实现两层聚合（最通用）
把第一层 GROUP BY 的结果当作临时表，第二层再对这个结果聚合。这是跨数据库兼容性最强的做法。
- 内层必须显式
GROUP BY，且所有非聚合列都要出现在该GROUP BY中 - 内层列必须用
AS显式命名，比如SUM(sales) AS dept_total - 子查询必须带别名，如
AS t，否则 MySQL 8.0+、PostgreSQL 会直接报错 - 外层不能加
GROUP BY，否则就变回分组查询，失去“对聚合结果再聚合”的目的
示例：
SELECT AVG(dept_total) FROM ( SELECT department, SUM(sales) AS dept_total FROM orders GROUP BY department ) AS t;
用 WITH CTE 替代子查询（提升可读性）
当逻辑超过两层，或中间结果需复用时，CTE 比嵌套子查询更清晰。它不改变执行计划，只优化表达。
-
WITH后每个 CTE 定义体必须独立闭合：AS ( ... )，漏一个)就报syntax error, expect RPAREN - CTE 名不能与真实表重名，否则 PostgreSQL 可能优先解析为基表
- CTE 内不能引用外层字段，避免作用域混淆；也不能在
OVER()里再嵌套聚合函数 - MySQL 5.7 不支持 CTE，若需兼容旧版，只能退回子查询写法
示例：
WITH dept_summary AS ( SELECT department, SUM(sales) AS dept_total FROM orders GROUP BY department ) SELECT AVG(dept_total), MAX(dept_total) FROM dept_summary;
窗口函数不是替代方案，而是另一条路
SUM(salary) OVER() 合法，但 SUM(AVG(salary)) OVER() 依然非法。窗口函数不折叠行数，适合保留明细 + 全局统计，无法产出标量二次聚合结果。
- 适用场景：每行算占比（
salary / SUM(salary) OVER()）、滚动求和、分组内排名 - 不适用场景：求“各城市平均房价的中位数”“部门平均薪资的方差”这类需要先降维再计算的指标
- 性能上，窗口函数通常比子查询快，但前提是你不需要最终一个标量值
真正容易被忽略的是：很多开发者试图用窗口函数“绕过”嵌套限制，结果发现返回的是 N 行而非 1 行，和业务需求根本不匹配。
