avg(sum(x))在sql中非法，因标准禁止聚合函数嵌套、语义不明确；必须用子查询或cte分两层实现，如select avg(dept_total) from (select sum(sales) as dept_total from orders group by dept_id) as t。
AVG(SUM(x)) 这类写法在任何主流 SQL 引擎里都会直接报错，不是配置问题，也不是版本差异，而是 SQL 标准本身禁止聚合函数嵌套——解析器在语法分析（analysis）阶段就拒绝，根本不会进入执行。
为什么解析器直接报错而不是执行时报错
错误信息通常是 aggregate function calls cannot be nested（PostgreSQL）、Invalid use of aggregate function（SQL Server）或 Invalid group function nesting（MySQL 5.7+）。这不是运行时异常，而是语法树构建失败：引擎看到 AVG(SUM(x)) 就知道语义冲突，连执行计划都不会生成。
-
SUM(x)必须依赖GROUP BY才能产出一组值；没有分组，它只返回一个标量 -
AVG()需要一组输入值才能计算，但它无法确定这“一组”该从哪来：是全表？按某列分组？还是子查询结果？ - SQL 执行顺序中，
GROUP BY和聚合发生在SELECT阶段，而嵌套会让引擎无法判断内外层的作用域和计算时机
哪些写法看似嵌套但其实合法
别被表面迷惑：COUNT(DISTINCT col) 是单个聚合函数的语法糖，不是真嵌套；SUM(x) OVER (PARTITION BY y) 是窗口函数，也不违反规则。但以下全部非法：
SUM(AVG(salary))MAX(MIN(create_time))-
AVG(SUM(amount)) OVER()（窗口函数里也不能嵌套聚合） -
ROUND(AVG(price))（标量函数包裹聚合函数，Oracle/Spark SQL 会报ORA-00907）
子查询为什么能绕过这个限制
子查询把第一层聚合“固化”成物理行集，让外层能把它当普通表处理。关键点在于：
- 内层必须有
GROUP BY，否则SUM(x)只返回一行，外层AVG()就只是对单个数求平均 - 内层列必须用
AS显式命名，比如SUM(sales) AS dept_total - 子查询必须带别名，如
AS t，否则 MySQL/PostgreSQL/SQL Server 全部报错 - 外层不能加
GROUP BY，否则又退化为分组聚合，失去“对聚合结果再聚合”的目的
CTE 和窗口函数不是等价替代方案
CTE 本质是语法糖，和子查询执行逻辑一致，但可读性更好；窗口函数则走的是另一条路——它不折叠行数，适合保留明细同时补全局统计。但要注意：
-
WITH在 MySQL 5.7 及更早版本不支持，旧环境只能用子查询 -
AVG(SUM(x)) OVER()依然非法，正确写法是先用SUM(x) OVER(PARTITION BY y)算出每组值，再用AVG() OVER()对这些值取平均（需确保分区后结果集稳定） - 窗口函数不能出现在
WHERE或HAVING中，因为它的计算时机晚于这两个子句
最常被忽略的一点：即使语法通过、结果看起来对，如果子查询里没加 ORDER BY 就用 ROW_NUMBER()，或者分区字段缺少索引，性能可能断崖式下降——这比语法错误更难排查。
