avg(sum(x))在任何主流sql引擎中均非法，因sql标准禁止嵌套聚合函数；必须用派生表、cte或窗口函数分两层实现，其中派生表最通用，cte可读性更好，窗口函数适用于保留明细行场景。
AVG(SUM(x)) 这类写法在任何主流 SQL 引擎里都会直接报错，不是你写错了括号，也不是数据有问题，而是 SQL 解析器在语法分析阶段就拒绝它——根本没机会执行。
为什么 AVG(SUM(x)) 会触发 AnalysisException
错误信息通常是 "aggregate function cannot contain aggregate parameters" 或 "cannot nest aggregate functions"。这不是数据库版本差异，是 SQL 执行模型的硬性限制：
-
SUM(x)必须配合GROUP BY在分组内运行，输出“每组一个值” -
AVG()需要输入“一组值”，但SUM(x)没有明确告诉引擎“这一组值”从哪来、按什么维度组织 - WHERE 阶段不能用聚合函数，SELECT 阶段虽已分组，但每个聚合只返回标量，外层无法从中提取序列
-
COUNT(DISTINCT col)看似嵌套，实为单函数语法糖，不在此列；但SUM(AVG(y))、MAX(MIN(z))全部非法
GROUP BY 缺失或错位导致语义无效
常见错误写法：SELECT SUM(MIN(create_time)) FROM t —— MIN() 没有作用域，SQL 引擎不知道对谁取最小值。
- 内层必须显式
GROUP BY，且所有非聚合列都要出现在该GROUP BY中 - 例如想算“每个用户的最早创建时间之和”，必须先
GROUP BY user_id，再对外层结果求和 - 漏掉
GROUP BY，SUM(MIN(x))就变成全表单值计算，外层AVG()实际只对一个数操作，业务意义丢失
子查询别名和字段引用容易踩坑
即使逻辑正确，语法细节出错也会让查询失败。
- 子查询必须带别名，如
AS t；SQL Server和PostgreSQL强制要求，漏掉直接报错 - 外层只能引用子查询中
SELECT明确写出的字段，比如AVG(t.total_per_user)合法，AVG(t.amount)非法（amount不在子查询结果中） -
MySQL 8.0+、PostgreSQL、Snowflake都要求子查询别名，不能省略
CTE 的括号闭合和作用域限制
CTE 看起来更清晰，但括号和命名规则比子查询更严格。
- 每个 CTE 定义体必须独立闭合：
WITH dept_avg AS (SELECT ... GROUP BY department)，漏一个)就报syntax error, expect RPAREN - CTE 名不能与真实表重名，否则
PostgreSQL可能优先解析为基表 - CTE 内不能引用外层字段，避免作用域混淆；也不能在
OVER()里再嵌套聚合函数 -
MySQL 5.7及更早不支持 CTE，若需兼容旧版，子查询是唯一选择
真正容易被忽略的是：外层聚合是否隐含了加权偏差。比如用 AVG(AVG(sale)) 替代 AVG(SUM(sale))，表面结果相近，但若各分组行数差异大，“平均的平均”会扭曲真实均值——这已经不是语法问题，而是业务逻辑是否经得起推敲的问题。
