AVG(SUM(x))在SQL中非法，因SQL标准禁止聚合函数嵌套，语义不明确；必须用子查询或CTE先分组再聚合，窗口函数无法替代。
AVG(SUM(x)) 这类写法在任何主流 SQL 引擎里都会直接报错，不是配置或版本问题，而是 SQL 标准本身禁止聚合函数嵌套——语义不明确，解析阶段就被拒绝。
为什么 AVG(SUM(x)) 会触发 semantic analysis exception 或 aggregate function cannot contain aggregate parameters
错误不是发生在执行时，而是在语法分析（analysis）阶段就失败。引擎根本不会生成执行计划，因为：
- SUM(x) 必须配合 GROUP BY 才能产生一组值，否则只返回单个标量
- AVG() 需要输入一个值序列，但它无法从 SUM(x) 的上下文中推断“这组值”到底属于哪个维度
- WHERE 里不能用聚合函数，GROUP BY 里也不能放聚合表达式，SELECT 列表中嵌套聚合直接违反执行模型顺序
- COUNT(DISTINCT col) 是特例，它是单函数语法糖，不在此列；但 MAX(AVG(y))、SUM(AVG(z))、ROUND(AVG(x)) OVER() 全部非法
用子查询实现两层聚合（最通用、跨库兼容）
把第一层分组结果固化为派生表，外层再对这个结果集做聚合。这是 MySQL 5.7+、PostgreSQL、SQL Server、Oracle 都支持的写法：
- 内层必须有 GROUP BY，否则 SUM(x) 算的是全表总和，外层 AVG() 就只是对一个数求平均
- 内层列必须用 AS 显式命名，比如 SUM(sales) AS dept_total
- 子查询必须带别名，如 AS t，否则 PostgreSQL 和 SQL Server 直接报 subquery in FROM must have an alias
- 外层不能加 GROUP BY，否则又变回分组查询，失去“对聚合结果再聚合”的目的
- 过滤条件要按层级放：WHERE price > 100 放内层（筛原始行），HAVING AVG(price) > 100 或外层 WHERE dept_total > 5000 放对应位置
SELECT AVG(dept_total) FROM ( SELECT department, SUM(sales) AS dept_total FROM orders GROUP BY department ) AS t;
用 WITH CTE 替代子查询（可读性更好，但注意兼容性）
CTE 不改变执行逻辑，只提升表达清晰度，尤其适合中间结果需复用或多层汇总场景：
- CTE 定义体必须闭合： AS ( ... )，漏一个 ) 就报 syntax error, expect RPAREN
- CTE 名不能与真实表重名，否则 PostgreSQL 可能优先解析为基表
- CTE 内不能引用外层字段，避免作用域混淆
- MySQL 5.7 及更早、旧版 SQLite 不支持 CTE，此时子查询是唯一选择
- 可单独运行中间步骤调试，比如先查 SELECT * FROM dept_summary 看数据是否符合预期
WITH dept_summary AS ( SELECT department, SUM(sales) AS dept_total FROM orders GROUP BY department ) SELECT AVG(dept_total), MAX(dept_total) FROM dept_summary;
真正容易被忽略的点是：窗口函数不是替代方案。写成 AVG(SUM(x)) OVER() 或 ROUND(AVG(y)) OVER() 依然非法——它连语法解析都过不去。需要二次聚合，就必须让第一层结果“落地”成行集，而不是依赖计算时的逻辑视图。
