SQL禁止聚合函数嵌套（如AVG(SUM(x))），因其语义冲突；需用子查询或CTE实现多级聚合，如先按部门求和再求平均；窗口函数适用于保留明细行的同行计算，不替代分组聚合。
SQL聚合函数嵌套直接报错：不能在聚合函数内部再用聚合函数
绝大多数 SQL 引擎（如 MySQL 5.7+、PostgreSQL、SQL Server）明确禁止形如 AVG(SUM(x)) 或 COUNT(MAX(y)) 的写法，执行时会抛出类似 "Invalid use of group function" 或 "nested aggregate function" 的错误。
根本原因在于：聚合函数作用于一组行并返回单个值，而嵌套调用意味着你试图对“一个标量结果”再次聚合——这在语义上不成立，SQL 引擎也无法确定外层聚合的分组上下文。
- 不是语法限制，而是逻辑冲突：
SUM()已压缩一行或多行为一个数，AVG()再去“平均一个数”，毫无意义 - 例外仅存在于极少数场景，比如 PostgreSQL 支持
STRING_AGG(ARRAY_TO_STRING(...))这类非数值聚合链，但仍是字符串拼接逻辑，不是真正意义上的“聚合嵌套” - MySQL 8.0+ 允许在窗口函数中组合使用（如
AVG(SUM(x)) OVER (...)），但这是窗口计算，不是 GROUP BY 下的传统嵌套
想实现“先按 A 分组求和，再对这些和求平均”？必须用子查询或 CTE
真实需求往往是多级聚合，例如：“每个部门的销售额总和，再算所有部门平均销售额”。这不是嵌套函数能解决的，而是需要两阶段计算。
正确做法是把第一层聚合结果作为中间表，再对外层做第二次聚合：
SELECT AVG(dept_total) AS avg_dept_sales FROM ( SELECT dept_id, SUM(sale_amount) AS dept_total FROM sales GROUP BY dept_id ) t;
- 子查询里完成第一层分组（
GROUP BY dept_id）和聚合（SUM()） - 外层对子查询结果集（每行是一个部门的总和）应用
AVG()，此时已无分组冲突 - CTE 写法更清晰：
WITH dept_sum AS (SELECT dept_id, SUM(sale_amount) ... GROUP BY dept_id) SELECT AVG(dept_total) FROM dept_sum
GROUP BY 多列时，外层聚合容易误算“重复分组”
当原始数据含多维粒度（如日期 + 地区 + 产品），又想跨维度统计均值时，直接 GROUP BY date, region 后再套 AVG()，往往得不到想要的“全量平均”。
典型陷阱：用 SELECT date, region, AVG(sale) FROM t GROUP BY date, region 得到的是每个（日期, 地区）组合内的平均值；若想算“所有地区在该日期的平均销售额”，必须先按 date 聚合出每日总和，再对每日总和取平均——否则会因产品数量差异导致加权偏差。
- 错误写法：
SELECT date, AVG(sale) FROM t GROUP BY date→ 实际是每天所有记录的 sale 平均，未考虑地区权重 - 正确路径：先
GROUP BY date, region求各地区当日总和，再按date汇总为“日总销售额”，最后对日总销售额序列求AVG() - 漏掉中间层分组，会导致聚合基数错误，结果不可复现
窗口函数能绕过 GROUP BY 限制，但逻辑完全不同
如果目标不是“汇总后二次统计”，而是“保留明细行的同时显示聚合参考值”（如每行显示所在部门的平均工资），该用窗口函数，而不是嵌套聚合。
例如：SELECT name, dept, salary, AVG(salary) OVER (PARTITION BY dept) AS dept_avg —— 它不减少行数，也不要求 GROUP BY，且允许与普通列混选。
- 窗口函数的
OVER子句定义计算范围，与GROUP BY互斥；两者不能共存于同一 SELECT 列表（除非外层再套一层） -
AVG() OVER ()是全表平均，AVG() OVER (PARTITION BY x)是按 x 分组的平均，但都属于“同行计算”，不改变结果集行数 - 混淆窗口和分组聚合，是写出低效甚至错误 SQL 的常见源头
实际写多层聚合时，最易被忽略的是分组粒度与业务口径是否严格对齐。比如“月均销售额”究竟是“每月销售额的平均值”，还是“所有销售记录按月摊薄后的日均”，二者差一个 SUM/AVG 的顺序，结果可能差出数量级。
