SQL禁止嵌套聚合函数（如AVG(SUM(x))），因语义不明确且违反标准；必须用派生表、CTE或窗口函数分两层实现，其中派生表最通用，CTE可读性更好，窗口函数适用于保留明细行场景。
不能直接在同一个 SELECT 里对聚合结果再套一层聚合函数，比如 AVG(SUM(sales)) 会报错。必须拆成两层：先用 GROUP BY 或子查询产出中间聚合值，再在外层对这些值做第二次聚合。
为什么 AVG(SUM(x)) 一定报错？
SQL 标准禁止嵌套聚合函数，因为语义模糊——引擎无法判断你是想对每组的 SUM(x) 求平均，还是先全表求和再平均。所有主流数据库（PostgreSQL、MySQL 5.7+、SQL Server、Oracle）都会拒绝执行，错误信息类似：ERROR: aggregate function calls cannot be nested 或 Invalid use of aggregate function。
-
COUNT(DISTINCT col)是唯一例外，它本质是单个聚合函数的语法糖，不是真嵌套 - 窗口函数也不能绕过这条规则：
AVG(SUM(x)) OVER()同样非法 - 哪怕加了
GROUP BY，同一层级仍不允许聚合函数嵌套
用子查询实现两层聚合（最通用）
把第一层分组结果当作临时表，外层再聚合。这是兼容性最好、逻辑最直白的做法，适用于所有支持标准 SQL 的数据库。
- 子查询必须起别名，例如
AS t，漏掉会报错：subquery in FROM must have an alias - 外层不能有
GROUP BY，否则又变成分组聚合，达不到“对聚合结果再聚合”的目的 - 内层
SELECT中必须明确写出要复用的字段，比如SUM(sales) AS dept_total，外层才能引用dept_total
示例：算各部门销售额总和的平均值
SELECT AVG(dept_total) FROM ( SELECT SUM(sales) AS dept_total FROM orders GROUP BY dept_id ) AS t;
用 CTE 替代子查询（更易读，但需注意字段可见性）
CTE 不是语法糖，它让中间结果命名更清晰，尤其在多步二次加工时比嵌套子查询少出括号错误。但它不改变执行逻辑，仍需严格遵循字段暴露规则。
- CTE 中
SELECT出的字段，外层可直接引用；没SELECT的字段，外层查不到 - 多个 CTE 之间可以引用，但不能跨 CTE 引用未声明字段，比如
WITH a AS (...), b AS (SELECT * FROM a WHERE cnt > 5)合法，但b里突然用a.dept_name就会报错 - 如果后续还要按二次结果排序或
LIMIT，必须在外层加ORDER BY和LIMIT，GROUP BY内部不保证顺序
示例：计算各品类毛利率后取均值
WITH agg AS ( SELECT category, SUM(revenue) AS total_rev, SUM(cost) AS total_cost FROM orders GROUP BY category ) SELECT ROUND(AVG((total_rev - total_cost) / NULLIF(total_rev, 0)), 4) FROM agg;
容易被忽略的三个防御点
语法跑通不等于逻辑安全。线上环境里，真正崩掉的往往不是写法，而是没处理好的边界情况。
-
NULLIF(denominator, 0)必须加：哪怕业务上“成本不可能为 0”，数据库只看执行时值。没它，SUM(revenue) / SUM(cost)遇到SUM(cost) = 0直接报错 -
COALESCE(, 0)要看业务语义：如果某组根本没数据（比如新部门还没订单），SUM(sales)返回NULL，后续除法或比较会传播NULL；这时补 0 还是留NULL，取决于“无数据”是否等价于“0 元” -
ROUND(, 4)别省：浮点误差在百分比类指标上会放大，比如0.29999999999999993显示成 30% 前必须四舍五入，否则前端展示或下游判断可能出偏差
真正麻烦的不是怎么写两层聚合，而是哪一层该加 NULLIF、哪一层该 COALESCE、在哪一层做 ROUND——这些细节不写进 SQL，就只能靠人工核对报表数字是否合理。
