avg(sum(x))报错因sql标准禁止嵌套聚合函数，语义不明确：sum需group by分组计算，而avg需一组值输入，直接嵌套导致引擎无法确定分组上下文；必须用派生表、cte或窗口函数分两层实现。
为什么 AVG(SUM(x)) 会报错
SQL解析器在执行时严格区分“行级计算”和“分组后聚合”。SUM(x) 是一个聚合函数，它必须配合 GROUP BY 使用，作用于分组内的多行，返回单个值；而外层的 AVG() 需要一组值作为输入——但直接写 AVG(SUM(x)) 时，内层没有明确的分组上下文，SQL引擎无法确定“对谁求和、再对哪些和求平均”。这不是语法偷懒限制，而是执行模型决定的：聚合函数不能接受另一个未落地的聚合结果作为参数。
子查询实现嵌套聚合的最小可行写法
把第一次聚合的结果“物化”成一张临时表，再对外层做二次聚合。关键点是：子查询必须有别名，且外层只能引用子查询中明确 SELECT 出来的列。
SELECT AVG(total_per_user) FROM (SELECT user_id, SUM(amount) AS total_per_user FROM orders GROUP BY user_id) AS t- 子查询里的
GROUP BY user_id是必须的，否则SUM(amount)没有分组依据 - 外层不能写
AVG(t.amount)，因为amount在子查询结果中已不存在，只有total_per_user - 别名
AS t不可省略，多数数据库（如 PostgreSQL、MySQL 8.0+、Snowflake）强制要求
CTE 和子查询选哪个
语义完全等价，性能通常无差别，但可读性和维护性差异明显：
- 用 CTE 时，可以把每层逻辑命名，比如
WITH daily_revenue AS (...), monthly_avg AS (SELECT AVG(rev) FROM daily_revenue)，调试时能单独运行中间步骤 - 嵌套超过两层时，子查询容易出现括号错位或别名混淆，CTE 更易定位问题
- 某些旧版 MySQL（5.7 及之前）不支持 CTE，此时只能用子查询
- Impala 等分析型引擎对 CTE 支持较弱，子查询更稳妥
容易被忽略的加权偏差问题
嵌套聚合不是纯技术问题，更是业务理解陷阱。例如：
- 误写
SELECT AVG(sale) FROM t GROUP BY date, region→ 得到的是每个(日期,地区)组合的平均值，但若各地区订单数差异大，这个“平均的平均”会掩盖权重 - 正确做法是先按
date汇总每日总销售额，再对每日汇总值取平均：SELECT AVG(daily_total) FROM (SELECT date, SUM(sale) AS daily_total FROM t GROUP BY date) AS d - 这种偏差在报表中常表现为“日均销售额”数值异常偏低或偏高，排查时需回溯聚合层级是否漏掉了关键分组维度
