不能直接嵌套聚合函数（如AVG(SUM(x))），因SUM需GROUP BY分组输出单值，AVG需一组输入值，执行阶段冲突；必须用子查询或CTE分层实现，如SELECT AVG(total) FROM (SELECT SUM(x) AS total FROM t GROUP BY y) AS t。
直接说结论：不能在同一个 SELECT 层级里对 GROUP BY 结果做二次聚合（比如 AVG(SUM(x))），也不能用 HAVING 实现跨组比较或依赖外部聚合值的筛选——必须拆成两层，用子查询或 CTE 固化中间结果。
为什么 AVG(SUM(x)) 会报错
这不是语法糖缺失，而是 SQL 执行阶段冲突：SUM(x) 必须在 GROUP BY 后按组计算，而 AVG() 需要一个完整的结果集来算平均值，二者不在同一逻辑阶段。所有标准兼容引擎（MySQL、PostgreSQL、SQL Server）都会拒绝，错误提示通常是：
-
Invalid use of group function（MySQL） -
column must appear in the GROUP BY clause（PostgreSQL）
本质是语义非法，不是版本或配置问题。
用子查询实现二次聚合最通用
把第一层分组结果当临时表，外层再聚合。关键三点必须同时满足：
- 内层
SELECT必须有GROUP BY，且所有非聚合字段都出现在GROUP BY中 - 内层查询必须起别名，例如
AS customer_summary，否则外层无法引用字段 - 外层不能再写
GROUP BY，否则又变成分组，达不到“对聚合结果整体再算一次”的目的
示例：算「每位客户总消费的平均值」
SELECT AVG(customer_total_spend) FROM ( SELECT customer_id, SUM(order_amount) AS customer_total_spend FROM orders GROUP BY customer_id ) AS customer_summary;
用 HAVING 筛选分组结果的边界在哪
HAVING 只能筛“本组是否达标”，不能做跨组比较。它合法的条件只能是：
-
GROUP BY中出现的列（如category） - 聚合函数（如
COUNT(*) > 5、SUM(amount) > 10000） - 外层
SELECT中定义的聚合别名（MySQL 8.0+、PostgreSQL 支持；SQLite 不支持）
但以下写法一定错：
-
HAVING SUM(amount) > (SELECT AVG(amount) FROM orders)—— 子查询在HAVING内会被重复执行，且语义上不属于“本组判断” -
HAVING status = 'active'——status没参与分组也没聚合，数据库直接报错
想筛“销售额高于全局均值的品类”，必须用 CTE 或子查询先算出均值，再 JOIN 或 WHERE 比较。
CTE 更易读，但要注意物化陷阱
CTE 在多层逻辑中可读性明显优于嵌套子查询，比如先算各客户总消费，再筛高价值客户，最后求他们平均订单数：
WITH customer_spends AS ( SELECT customer_id, SUM(order_amount) AS total_spend FROM orders GROUP BY customer_id ), high_value_customers AS ( SELECT customer_id FROM customer_spends WHERE total_spend > (SELECT AVG(total_spend) FROM customer_spends) ) SELECT AVG(order_count) FROM ( SELECT c.customer_id, COUNT(*) AS order_count FROM orders c INNER JOIN high_value_customers h ON c.customer_id = h.customer_id GROUP BY c.customer_id ) AS t;
但注意：CTE 默认不物化，大表上可能重复执行 customer_spends 两次。PostgreSQL 支持 MATERIALIZED 提示，MySQL 8.0+ 则需靠临时表或重写为子查询手动缓存。
真正容易被忽略的是防御性处理：二次聚合时，NULLIF(denominator, 0) 不是可选项，是必选项；ROUND(..., 4) 不是美观需求，是避免浮点误差影响下游判断的硬要求；而 CTE 中字段别名一旦漏定义，外层引用就直接失败——这些细节在线上环境往往比语法错误更难排查。
