正确计算分组内累计百分比应使用SUM() OVER(PARTITION BY...ORDER BY...)÷SUM() OVER(PARTITION BY...)，分子需带ROWS UNBOUNDED PRECEDING确保顺序，分母用NULLIF防除零，且须与分子严格对齐分组边界。
分组内累计百分比的正确计算逻辑
想准确算出分组内的累计百分比，最可靠的方法就是：先用SUM() OVER计算累计和，再除以该分组的总和。这个逻辑听起来简单，但实际操作中，不少人会误用COUNT(*) OVER或者全局的SUM()，结果导致百分比加起来不等于100%——尤其是在分组内存在重复值或NULL的时候，数据就“漂移”了。
核心公式其实很清晰：SUM(value) OVER (PARTITION BY group_col ORDER BY sort_col ROWS UNBOUNDED PRECEDING) ÷ SUM(value) OVER (PARTITION BY group_col)
- 分子必须带上
ORDER BY：否则窗口函数根本不知道“累计”的顺序是什么，结果自然不可控。 - 分母不能写成常量或子查询：必须使用同级的
SUM() OVER (PARTITION BY ...)，这样才能确保分子和分母的分组边界完全对齐。 - 如果
value列包含NULL，SUM()函数会自动忽略，但这里需要确认业务逻辑是否允许跳过这些值。如果不允许，记得先用COALESCE(value, 0)处理一下。
MySQL 8.0+ 和 PostgreSQL 中的写法差异
虽然两者的语法看起来一致，但细节上有个关键区别：MySQL对ROWS UNBOUNDED PRECEDING这个子句更敏感。如果省略它，窗口可能会退回到RANGE模式，当排序键出现重复值时，就会多算一行，导致累计值虚高。
简单来说，PostgreSQL允许省略ROWS子句，默认按行处理；而MySQL默认是RANGE模式，所以必须显式声明ROWS。
- 最安全的写法是统一加上
ROWS UNBOUNDED PRECEDING，避免兼容性问题。 - 排序字段必须具有确定性：如果使用时间戳，建议在后面追加主键，比如
ORDER BY created_at, id，这样可以避免相同时间戳打乱累计顺序。 - 在MySQL中尤其要注意，如果漏写了
PARTITION BY，整个结果集会被当成一个组，分组百分比的计算就全错了。
常见错误现象：百分比超过 100% 或出现 NULL
工作中常会遇到一些典型的报错或异常：比如百分比列里出现了NULL，某个分组的第一行就显示120%，或者不同分组间的累计值出现跳跃。
- 分母为0导致全组NULL：整个分组的总和如果是0，除法就会出错。解决方法是在分母外包裹
NULLIF(SUM(...) OVER (...), 0)，防止除零错误。 - ORDER BY字段含NULL导致顺序混乱：累计窗口可能会把NULL值排在最前或最后，从而影响顺序。在PostgreSQL中可以用
ORDER BY col ASC NULLS LAST控制，MySQL则可以用ORDER BY IFNULL(col, '9999-12-31')这类方式显式处理。 - 用错函数导致语义错误：使用
COUNT(*) OVER (PARTITION BY ... ORDER BY ...)替代SUM(value)...，这算出来的是“行数占比”，而不是“数值占比”，业务语义完全不对。
实际可运行示例（以销售数据为例）
SELECT
region,
product,
amount,
SUM(amount) OVER (PARTITION BY region ORDER BY amount ROWS UNBOUNDED PRECEDING) AS cum_amount,
ROUND(
100.0 * SUM(amount) OVER (PARTITION BY region ORDER BY amount ROWS UNBOUNDED PRECEDING)
/ NULLIF(SUM(amount) OVER (PARTITION BY region), 0),
2
) AS cum_pct
FROM sales;
这里有几个细节值得注意：NULLIF用于防除零，而小数点后保留位数（如ROUND(..., 2)）是交付报表时的硬性要求，能避免浮点误差带来的困扰。另外，如果业务要求“按时间先后累计”，只需把ORDER BY amount换成ORDER BY sale_date即可——顺序一变，计算语义就完全不同了，这一点特别容易被忽略。
