SUM(SUM(column))非法因聚合函数不可嵌套，正确写法是SUM(column)/SUM(column)OVER()计算分组占比，需配合GROUP BY并处理NULL与除零。
为什么 SUM(column) / SUM(SUM(column)) OVER() 会报错
直接写 SUM(col) / SUM(SUM(col)) OVER() 在绝大多数 SQL 引擎（如 PostgreSQL、SQL Server、BigQuery）里会报错，典型错误是 aggregate function calls cannot be nested —— 聚合函数不能嵌套。也就是说，SUM(SUM(col)) 语法非法，不管它在 OVER 里还是外面。
真正想表达的其实是「当前分组的和」除以「全表所有分组的总和」，即：分组占比 = SUM(col) / SUM(col) OVER()。
-
SUM(col) OVER()是窗口聚合，对整张结果集（未分组前或按指定 PARTITION BY 后）求和，不破坏 GROUP BY 结构 - 必须确保外层有
GROUP BY，否则SUM(col)没有分组上下文，语义模糊 - 如果漏写
GROUP BY，PostgreSQL 会报column must appear in the GROUP BY clause；MySQL 8.0+ 默认 SQL mode 下也会拒绝
正确写法：用 SUM() OVER() 替代嵌套 SUM(SUM())
核心是把“全量总和”抽出来作为窗口计算，和分组聚合并行执行。例如统计每类订单金额占总金额的百分比：
SELECT category, SUM(amount) AS category_total, ROUND(100.0 * SUM(amount) / SUM(amount) OVER(), 2) AS pct FROM orders GROUP BY category;
-
SUM(amount) OVER()计算的是整个orders表的amount总和，不受GROUP BY影响 -
100.0 *是为了强制浮点运算，避免整数除法截断（比如 SQLite 或旧版 MySQL 可能返回 0） - 如果需要按某维度再分区（如只算「每个地区内各类别占比」），就写成
SUM(amount) OVER(PARTITION BY region)，并在GROUP BY中包含region
MySQL 5.7 或低版本兼容写法
MySQL 5.7 不支持窗口函数，SUM() OVER() 会直接报错 ERROR 1064。此时只能用子查询或 JOIN 模拟：
SELECT t1.category, t1.category_total, ROUND(100.0 * t1.category_total / t2.total, 2) AS pct FROM ( SELECT category, SUM(amount) AS category_total FROM orders GROUP BY category ) t1 CROSS JOIN ( SELECT SUM(amount) AS total FROM orders ) t2;
- 子查询
t2提前算出全表总和，一行一列，CROSS JOIN确保它广播到每一行 - 不能用
LEFT JOIN或带条件的JOIN，否则可能丢行或重复 - 注意
SUM(amount)在子查询中若遇 NULL，结果为 NULL，建议加COALESCE(SUM(amount), 0)
容易被忽略的 NULL 和精度问题
真实数据里 amount 字段常含 NULL，而 SUM() 会自动忽略 NULL，但除零或隐式类型转换仍可能出问题：
- 如果全表
amount全为 NULL 或总和为 0，SUM(amount) OVER()返回 0，除法会触发division by zero错误（PostgreSQL）或返回NULL（MySQL） - 稳妥做法是包裹
NULLIF(SUM(amount) OVER(), 0)，例如：SUM(amount) / NULLIF(SUM(amount) OVER(), 0) - 百分比保留小数位数建议显式用
ROUND(..., 2)，而不是依赖数据库默认输出格式，尤其当后续要导出或做比较时 - 某些引擎（如 Presto/Trino）对
DECIMAL类型除法更敏感，需确保分子分母至少一个是浮点字面量（如100.0）
实际跑通的关键不在“怎么嵌套”，而在理解 SUM() OVER() 是独立于 GROUP BY 的并行计算通道。一旦混淆了聚合层级，就容易卡在语法报错或结果偏差上。
