正确写法是分子用sum() over (order by ...)计算累积和，分母用静态标量（如子查询或cte求得的全局总和），避免分母也用窗口函数导致结果恒为1或错误。
直接用 SUM() OVER() 除以总和即可，但必须注意分母是静态总数，不能也写成窗口函数——否则会得到 1.0 或错误结果。
为什么 SUM(x) OVER() / SUM(x) OVER() 是错的
这个写法看似对称，实则分母也变成了逐行累积和（或全表和，取决于 OVER 子句），导致每行分子分母同构，结果恒为 1（若未加 ORDER BY）或产生非预期比例。累积比例要求分母固定为整个数据集的总和。
常见错误现象：SUM(x) OVER (ORDER BY id) / SUM(x) OVER () 看似合理，但若 OVER() 无 PARTITION BY，分母确实是全表和，此时可工作；但一旦加了分区，分母就随分区变化，而你可能想要的是全局占比——这点极易混淆。
- 用
SUM(x) OVER ()当分母：仅适用于“全表总数”场景，且需确认未被隐式PARTITION BY影响 - 更稳妥做法：先用子查询或 CTE 算出全局
SUM(x)，再 JOIN 或引用 - 某些数据库（如 PostgreSQL）支持在窗口函数外直接引用聚合结果，但标准 SQL 不保证，别依赖
SUM() OVER (ORDER BY ...) 计算累积值，再除以静态总数
这是最常用、最清晰的累积比例写法。关键在于：分子是带 ORDER BY 的窗口累积和，分母是确定不变的标量。
示例（按销售额递增顺序计算累积占比）：
SELECT product, sales, SUM(sales) OVER (ORDER BY sales) AS cum_sales, ROUND(SUM(sales) OVER (ORDER BY sales) * 1.0 / (SELECT SUM(sales) FROM orders), 4) AS cum_pct FROM orders;
说明：
-
SUM(sales) OVER (ORDER BY sales)每行返回截止当前sales值的累积和 -
(SELECT SUM(sales) FROM orders)强制为标量，不受外部ORDER BY或行影响 - 乘
* 1.0是为避免整数除法截断（尤其在 PostgreSQL、SQL Server 中） - MySQL 8.0+、PostgreSQL、Oracle、SQL Server 均支持；SQLite 不支持窗口函数
用 CTE 预先计算总数，提升可读性与复用性
当逻辑变复杂（比如要同时算多个指标的累积比例，或需多次引用总数），CTE 比重复子查询更安全、易维护。
示例：
WITH total AS ( SELECT SUM(sales) AS total_sales FROM orders ) SELECT o.product, o.sales, SUM(o.sales) OVER (ORDER BY o.sales, o.product) AS cum_sales, ROUND(SUM(o.sales) OVER (ORDER BY o.sales, o.product) * 1.0 / t.total_sales, 4) AS cum_pct FROM orders o CROSS JOIN total t;
优势：
- 总数只算一次，避免优化器误判重复子查询执行次数
- 排序键加
o.product是为避免sales相同时累积和顺序不确定（导致比例抖动） -
CROSS JOIN在单行 CTE 下等价于变量绑定，语义明确
NULL 和零值处理必须显式考虑
如果 sales 列含 NULL，SUM() 会自动忽略，但你可能需要补零或报错；如果总数为 0，除法会报错或返回 NULL，生产环境必须拦截。
- 用
COALESCE(sales, 0)统一处理NULL为 0（根据业务含义决定是否合理） - 分母用
NULLIF((SELECT SUM(sales)...), 0)避免除零，再配合COALESCE(..., 0)返回默认值 - 例如：
COALESCE(SUM(sales) OVER (...) * 1.0 / NULLIF((SELECT SUM(sales) FROM orders), 0), 0)
真正麻烦的不是语法，而是搞清你要的“总数”到底属于哪一层——是全表？某个时间范围？还是某类客户下的总和？窗口函数本身不帮你做业务切片，它只忠实地按 OVER 子句执行。写之前，先在纸上画清楚分子怎么走、分母钉在哪。
