sql聚合函数不能直接嵌套，如avg(sum(x))会报错，因内层sum需group by生成多行结果，而外层avg需独立结果集；必须用子查询或cte分两步实现，且子查询须有别名、合理索引与执行计划分析。
SQL里不能直接写 AVG(SUM(x)) 或 SUM(MIN(y))，这不是语法疏忽，而是执行模型决定的——聚合函数作用于分组后的一行结果，而外层聚合需要多行输入。必须拆成两步。
为什么 SELECT AVG(SUM(amount)) FROM t GROUP BY id 会报错
这条语句在绝大多数数据库（MySQL、PostgreSQL、SQL Server、Snowflake）中都会拒绝执行，错误信息通常是类似 Invalid use of group function 或 misuse of aggregate function。原因很直接：
- 内层
SUM(amount)必须配合GROUP BY id才能算出每组一个值； - 但外层
AVG()没有自己独立的GROUP BY，它期望操作的是“一个结果集”，而不是“嵌套在聚合上下文里的单个标量”； - SQL 标准规定：聚合函数不能作为另一个聚合函数的直接参数。
用子查询实现嵌套聚合的硬性要求
子查询方案看似简单，但漏掉任一细节就会失败：
- 子查询必须有别名，例如
AS customer_summary—— 否则报错Every derived table must have its own alias； - 外层只能引用子查询
SELECT列表中的字段，不能访问原始表字段（比如子查询里没选customer_id，外层就无法GROUP BY customer_id）； - 子查询中若用了
GROUP BY，其结果就是“已聚合”的逻辑表，不能再加WHERE过滤原始行（要过滤得提前到子查询里）； - 性能上，子查询结果会被物化（尤其在 MySQL 中），大数据量时可能吃光临时表空间。
CTE 比子查询更清晰，但不是万能的
CTE（WITH 子句）只是语法糖，不改变执行逻辑，但它能显著降低理解成本：
- 多层聚合时，每层命名明确，比如
WITH daily_sales AS (...), region_avg AS (...)； - 同一 CTE 可被多次引用（如既算
AVG()又算MAX()），避免重复写子查询； - 注意 Snowflake/PostgreSQL 支持
MATERIALIZEDCTE 控制物化行为，但 MySQL 不支持，CTE 在 MySQL 8.0+ 中仍是非物化的（每次引用都重算）； - 别以为 CTE 就一定快——如果底层没索引，CTE 只是把慢查询写得好看点。
容易被忽略的性能陷阱
真正卡住业务的往往不是语法，而是数据规模和索引缺失：
- 子查询内层
GROUP BY a, b，却只在(a)上建了索引？那Using temporary; Using filesort几乎必现； - 千万级订单表按
user_id聚合再求平均，没加WHERE created_at > '2025-01-01'过滤？全表扫描直接拖垮； - 想算“每个用户最近3次订单金额的平均值”，用子查询 +
ROW_NUMBER()窗口函数比嵌套聚合更自然，也更容易走索引； - 高频运行的嵌套聚合，应考虑预计算到汇总表或物化视图，而不是每次实时算。
最常被跳过的动作是：在写完嵌套结构后，不看 EXPLAIN 或执行计划，就直接上线。而真正决定快慢的，从来不是“用了 CTE 还是子查询”，而是中间结果集有多大、有没有落到磁盘、索引是否命中。
