avg(sum(x))直接报错，因sql标准禁止聚合函数嵌套：sum需group by分组输出单值，avg需一组输入值，二者执行上下文冲突，引擎无法推断分组维度；必须用子查询或cte分层实现。
AVG(SUM(x)) 为什么直接报错
SQL 引擎在解析阶段就拒绝 AVG(SUM(x)) 这类写法，错误信息通常是 Cannot perform an aggregate function on an expression containing an aggregate（SQL Server）、aggregate function calls cannot be nested（PostgreSQL）或 Invalid group function nesting（MySQL 5.7+）。这不是数据库版本问题，而是 SQL 标准强制规定：聚合函数必须作用于已分组的行集，返回单个标量值；而外层聚合（如 AVG()）需要一组值作为输入——SUM(x) 没有明确“这一组值”从哪来，引擎无法推断分组上下文。
子查询实现两层聚合的硬性要求
把第一层聚合结果当作临时表，是跨数据库最通用的做法。但漏掉任一细节都会报错：
-
GROUP BY在子查询里不可省：写SELECT SUM(amount) FROM orders得到单个值，外层AVG()就只是对一个数求平均，失去业务意义 - 子查询必须带别名：例如
AS t，否则 PostgreSQL/MySQL 8.0+/SQL Server 直接报subquery in FROM must have an alias或Incorrect syntax near ')' - 外层只能引用子查询中显式
SELECT出来的列：比如子查询写了SUM(sales) AS dept_total，外层可用AVG(t.dept_total)，但AVG(t.sales)会报invalid column name
CTE 与子查询选哪个
语义等价，性能通常无差别，但实操差异明显：
- CTE 更适合调试和多层逻辑：比如
WITH daily_sum AS (SELECT date, SUM(sales) s FROM orders GROUP BY date)，可单独运行SELECT * FROM daily_sum验证中间结果 - 嵌套超过两层时，子查询容易括号错位、别名混淆；CTE 分段命名（如
dept_agg、region_avg）更易定位问题 - MySQL 5.7 及更早版本不支持 CTE，Impala 对 CTE 支持弱，此时子查询是唯一选择
窗口函数不是嵌套替代方案
有人误以为 AVG(SUM(x)) OVER() 能绕过限制，但它在所有标准数据库中依然非法。窗口函数解决的是另一类问题：
-
SUM(amount) OVER (PARTITION BY dept_id)是给每行补上部门总和，行数不变，不产生新分组 - 若真需要“所有部门总和的平均值”，正确写法是先用
SUM() OVER (PARTITION BY dept_id)算出每行对应的部门总和，再用AVG() OVER()对这些值取平均——但这依赖去重或额外处理，逻辑不如子查询清晰 - 窗口函数无法替代
GROUP BY后的降维聚合，比如“每个用户订单总额的中位数”，仍需子查询或 CTE 落地中间结果
真正容易被忽略的不是语法怎么写，而是业务含义是否被扭曲：比如用 SELECT date, AVG(sale) FROM t GROUP BY date 看似合理，但如果每天各地区订单量差异极大，这个“日均”其实是简单算术平均，掩盖了权重偏差。要得到真实日均销售额，必须先按日期汇总每日总销售额，再对这些汇总值求平均——聚合层级错一层，结果就偏得没边。
