SQL禁止嵌套聚合函数（如AVG(SUM(x))），因语义不明确且违反标准；必须用派生表、窗口函数或CTE分两层实现，其中派生表最通用，CTE可读性更好，窗口函数适用于保留明细行场景。
SQL 不能直接在同一个 SELECT 中对聚合结果再用聚合函数（比如 AVG(SUM(x))），会报错 ERROR: aggregate function calls cannot be nested。必须拆成两层：要么用子查询/派生表，要么用窗口函数替代。
为什么 SUM 里面套 AVG 会报错
SQL 标准规定，聚合函数不能嵌套调用——因为聚合是按 GROUP BY 分组后逐组计算的，AVG(SUM(x)) 的语义不明确：是对每组的 SUM(x) 再求平均？还是先全表求和再平均？引擎拒绝猜测。
常见错误现象：ERROR: aggregate function calls cannot be nested（PostgreSQL）、Invalid use of aggregate function（SQL Server）、或 MySQL 5.7+ 的 Invalid group function nesting。
- MySQL 5.7+ 默认 SQL 模式下严格禁止嵌套；8.0 同样报错
- PostgreSQL、Oracle、SQL Server 全部不支持
- 唯一“看起来像嵌套”的例外是
COUNT(DISTINCT col)，但它本质是单个聚合函数的变体，不是真嵌套
用派生表实现两层聚合（最通用）
把第一层聚合结果当做一个临时表（即派生表），第二层再对它聚合。这是兼容性最好、逻辑最清晰的做法。
使用场景：想统计“每个部门销售额总和的平均值”，即先按部门 SUM(sales)，再对这些部门级总和求 AVG()。
实操建议：
- 外层查询不能有
GROUP BY，否则又变成分组聚合，失去“对聚合结果再聚合”的本意 - 派生表必须起别名（哪怕只是
AS t），否则多数数据库报错subquery in FROM must have an alias - 列名在派生表里要明确，避免外层引用时模糊
示例（统计各部门销售额均值）：
SELECT AVG(dept_total) FROM ( SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id ) AS t;
用窗口函数替代（更高效，但有局限）
如果目标是“在保留明细行的同时，算出某聚合值的全局统计（如所有组的平均值）”，窗口函数比派生表更轻量，且避免了二次扫描。
使用场景：查出每个部门的销售额，同时显示“所有部门销售额总和的平均值”作为参考列。
注意点：
-
AVG(SUM(sales)) OVER()依然非法——窗口函数也不能嵌套聚合 - 正确写法是先用
SUM() OVER(PARTITION BY dept_id)算部门总和，再套一层AVG() OVER()对这些部门总和取平均 - 但注意：这等价于
AVG() OVER()作用在去重后的部门总和上，需配合DISTINCT或子查询确保逻辑一致
稳妥写法（推荐）：
SELECT DISTINCT AVG(dept_total) OVER() AS avg_dept_total FROM ( SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id ) AS t;
MySQL 8.0+ 的 CTE 写法（可读性更好）
相比嵌套子查询，CTE 让两层逻辑分离更干净，调试和复用也方便，但底层执行计划通常和派生表无异。
实操建议：
- CTE 名称要反映语义，比如
dept_sales比t1更易懂 - 不要在 CTE 里写
ORDER BY或LIMIT（除非配合OFFSET做分页），部分数据库不支持 - CTE 是逻辑定义，不是物化视图；重复引用同一 CTE 可能被多次执行（MySQL 8.0.23+ 支持
MATERIALIZED提示，但非常规）
示例：
WITH dept_sales AS ( SELECT SUM(sales) AS total FROM orders GROUP BY dept_id ) SELECT AVG(total) FROM dept_sales;
真正容易被忽略的是：派生表或 CTE 中的 GROUP BY 维度，必须恰好是你想“再聚合”的单位。少一个字段，就可能把不该合并的组压在一起；多一个字段，又会让第一层结果颗粒度太细，导致第二层聚合失去意义。逻辑断点在哪一层，得先想清楚。
