SUM(COUNT()) 一定报错，因 SQL 标准禁止嵌套聚合函数；COUNT() 产出每组单值，SUM() 需一组值，作用域冲突；正确做法是用子查询或 CTE 分两层实现。
不能直接写 SUM(COUNT())，所有主流 SQL 引擎都会在语法解析阶段报错，这不是数据问题，是 SQL 标准硬性禁止。
为什么 SUM(COUNT()) 一定报错？
SQL 解析器看到 COUNT() 出现在另一个聚合函数参数里，会立刻拒绝——错误信息通常是 "aggregate function cannot contain aggregate parameters" 或 "cannot nest aggregate functions"。这不是版本兼容问题，而是执行模型决定的：COUNT() 必须配合 GROUP BY 输出“每组一个值”，而 SUM() 需要输入“一组值”，两者作用域和生命周期根本不匹配。
-
COUNT(*)和COUNT(col)是单层聚合，合法；COUNT(DISTINCT col)是语法糖，也不算嵌套 -
SUM(AVG(x))、MAX(MIN(y))、AVG(SUM(z))全部非法，原理相同 - 即使加了
GROUP BY，外层SUM(COUNT())依然不被允许——分组只解决内层作用域，不打通内外层语义链
正确做法：用子查询分两层实现
把内层聚合结果作为临时表（或 CTE），再在外层对它的结果做二次聚合。这是最通用、兼容性最好的解法。
- 子查询必须带别名，例如
AS t；MySQL/PostgreSQL/SQL Server 都强制要求，漏掉直接报Error Code: 1248 - 子查询中必须显式
GROUP BY，且所有非聚合字段都要出现在该GROUP BY中 - 外层只能引用子查询
SELECT列表中明确写出的字段，比如t.user_count合法，t.id非法（如果没选出来） - 示例：统计“每个部门的员工数之和”（即总员工数，但逻辑上经由部门粒度聚合）
SELECT SUM(t.emp_count) AS total_employees FROM ( SELECT dept_id, COUNT(*) AS emp_count FROM employees GROUP BY dept_id ) AS t;
替代方案：CTE 更易读，窗口函数适合保留明细
如果只是想让逻辑更清晰，或者需要同时看到明细和汇总，CTE 和窗口函数是两个实用选择。
- CTE 不改变执行逻辑，但可读性更好，尤其多层嵌套时：
WITH dept_counts AS (SELECT dept_id, COUNT(*) AS cnt FROM employees GROUP BY dept_id) SELECT SUM(cnt) FROM dept_counts - 窗口函数适用于需要“既按部门统计，又算全局总和”的场景，例如：
SELECT dept_id, COUNT(*) AS dept_cnt, SUM(COUNT(*)) OVER() AS total_cnt FROM employees GROUP BY dept_id - 注意：
SUM(COUNT(*)) OVER()合法，因为OVER()是窗口定义，不是嵌套聚合函数调用 - 但窗口函数无法替代子查询做跨维度聚合（比如先按用户聚合，再按地区求和），此时仍需子查询
容易踩的坑：NULL、类型、JOIN 膨胀全得一起防
子查询写对了，不代表结果就准——真实环境里，NULL、整型溢出、JOIN 导致的行数膨胀会悄悄污染结果。
- 子查询返回空集时，外层
SUM()会得到NULL，不是0；业务上是否允许“无数据=0”？如需保底，加COALESCE(SUM(t.emp_count), 0) - 如果
emp_count可能超 32 位整型范围，别等SUM()算完再CAST，要在子查询里就COUNT(*)::BIGINT或CAST(COUNT(*) AS BIGINT) - 若子查询涉及
JOIN（比如employees JOIN departments），先确认是否已因一对多导致行数膨胀；如有，必须在子查询最内层用DISTINCT或预聚合切掉重复，否则COUNT(*)就已经错了
真正难的从来不是写对语法，而是搞清每一层聚合的作用域、数据来源和 NULL 语义——这些细节不抠清楚，查出来的数看着对，其实早偏了。
