AVG(SUM(x))非法是因SQL标准禁止嵌套聚合，语义歧义且执行顺序冲突；正确做法是用派生表或CTE先分组聚合，再对外层结果求平均，如SELECT AVG(dept_total) FROM (SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id) AS t。
SQL 不允许 AVG(SUM(x)) 这类写法，不是语法偷懒，而是语义根本说不清——引擎没法判断你到底想对“每组的 SUM”求平均，还是先全表加总再除个数。
为什么 AVG(SUM(x)) 会报错
错误信息通常是：ERROR: aggregate function calls cannot be nested（PostgreSQL）、Invalid use of aggregate function（SQL Server）或 MySQL 5.7+ 的 Invalid group function nesting。这不是数据库版本问题，是 SQL 标准强制规定：聚合函数必须在 GROUP BY 完成后执行，而嵌套会让执行顺序和作用域产生歧义。
- WHERE 阶段还没分组，自然不能用任何聚合函数
- SELECT 阶段虽已分组，但每个聚合函数只输出一个标量值，
SUM(x)对每组返回一个数，AVG()却需要多个数才能算——它没地方取“多个” -
COUNT(DISTINCT col)看似嵌套，实为单函数语法糖，不违反规则
用派生表实现两层聚合（最通用）
把第一层 GROUP BY 结果当临时表，第二层再对这个临时表聚合。这是跨数据库兼容性最好、逻辑最直白的做法。
- 外层查询不能带
GROUP BY，否则又变回分组，失去“对聚合结果再聚合”的本意 - 派生表必须起别名，比如
AS t，否则 PostgreSQL/MySQL 8.0+ 直接报subquery in FROM must have an alias - 内层列要显式命名（如
SUM(sales) AS dept_total），避免外层引用时列名模糊
SELECT AVG(dept_total) FROM ( SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id ) AS t;
用 CTE 替代派生表（可读性更好）
CTE 不改变执行逻辑，但把“中间结果”命名后更易理解，尤其当第一层聚合本身较复杂时。
- CTE 名称不能和真实表重名，否则某些数据库（如 PostgreSQL）会优先解析为基表
- CTE 可被多次引用，适合需要复用同一聚合结果的场景（比如同时算
AVG和MAX） - MySQL 5.7 不支持 CTE，若需兼容旧版，只能退回派生表
WITH dept_summary AS ( SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id ) SELECT AVG(dept_total), MAX(dept_total) FROM dept_summary;
窗口函数能替代吗？要看场景
窗口函数不是“嵌套聚合”的解法，而是另一条路：它不折叠行数，适合既要明细又要全局统计的场景。
-
AVG(SUM(sales)) OVER()依然非法——窗口函数同样禁止聚合嵌套 - 正确写法是分两步：先用
SUM() OVER(PARTITION BY dept_id)算出每行对应的部门总和，再用AVG() OVER()对这些值取平均（注意：这其实隐含了一次去重，因每组所有行的部门总和相同） - 如果原始表有 100 行、10 个部门，窗口函数会输出 100 行，每行都带相同的
AVG(dept_total)；派生表 + 外层AVG只输出 1 行
真正容易被忽略的是：很多你以为的“嵌套需求”，其实本质是指标口径问题。比如想算“每天各地区销售额的平均值”，直接 AVG(sales) GROUP BY date, region 得到的是加权平均（销量大的地区影响更大）；而先按 date, region 求和、再按 date 求均值，才是无偏的日均地区表现——这种差异不会报错，但结果可能完全误导决策。
