AVG(SUM(x))必然报错，因SQL执行模型要求SUM需GROUP BY分组输出单值，而AVG需一组输入值，二者上下文冲突；必须用子查询或CTE分层实现，如SELECT AVG(total) FROM (SELECT SUM(x) AS total FROM t GROUP BY y) AS t。
AVG(SUM(x)) 这类写法在标准 SQL 中必然报错，不是数据库版本问题，而是执行模型决定的。
为什么 AVG(SUM(x)) 会直接报错
SQL 引擎在解析阶段就拒绝这种写法，错误信息类似 Cannot perform an aggregate function on an expression containing an aggregate。根本原因不是语法偷懒，而是两层聚合的执行上下文冲突：
-
SUM(x)必须配合GROUP BY在分组内运行，输出是“每组一个值” -
AVG()需要输入“一组值”，但SUM(x)没有明确它该对哪组结果求平均——是所有行？还是按某个未声明的维度分组？引擎无法推断 - WHERE 阶段也拦不住它，因为聚合函数压根不能出现在 WHERE 里（执行顺序：WHERE → GROUP BY → HAVING → SELECT）
子查询是最通用、最稳妥的替代方案
把第一次聚合“落地”成临时结果集，外层再对这个结果集做聚合。这是所有主流数据库（MySQL 5.7+、PostgreSQL、SQL Server、Oracle）都支持的写法：
- 子查询必须带别名，例如
FROM (SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id) AS t，漏掉AS t在 SQL Server 和 PostgreSQL 中直接报错 - 外层只能引用子查询中显式
SELECT出来的列，比如AVG(t.total)合法，AVG(t.amount)非法（amount不在子查询结果中） -
GROUP BY在子查询里不可省：如果子查询没GROUP BY，SUM(amount)返回单个值，外层AVG()就只是对一个数求平均，失去业务意义
CTE 更适合多层逻辑或调试场景
语义和子查询等价，但可读性更好，尤其当嵌套超过两层时：
- CTE 定义后可以单独运行中间步骤，比如
WITH daily_sum AS (SELECT date, SUM(sales) s FROM orders GROUP BY date)，后续可先查SELECT * FROM daily_sum看数据是否符合预期 - SQL Server 对括号极其敏感，
WITH a AS (SELECT ...) SELECT ...多一个空格或少一个)就报syntax error, expect RPAREN - 旧版 MySQL（5.7 及之前）不支持 CTE，Impala 等分析引擎对 CTE 支持弱，此时子查询是唯一选择
窗口函数不是嵌套聚合的替代品
有人误以为 AVG(SUM(x)) OVER() 能绕过限制，但它在所有标准数据库中依然非法。窗口函数解决的是另一类问题：
-
SUM(x) OVER (PARTITION BY dept_id)是给每一行补上部门总和，不改变行数，也不产生新分组 - 若真需要“对部门总和再求平均”，仍得两步走：先用窗口函数或子查询算出每个部门的总和，再套一层
AVG()查询那个结果集 - 注意空值：窗口函数默认把
NULL归为同一组，而GROUP BY通常跳过NULL，行为不一致可能引发偏差
最容易被忽略的不是语法怎么写，而是业务含义是否被扭曲——比如用 AVG(sale) GROUP BY date, region 算出的“日均地区销售额”，实际是加权平均，受各地区订单量影响；真正想算“每天所有地区的简单平均”，必须先按 date 聚合出每日总额，再对外层结果取 AVG。
