SQL如何实现累计占比统计_SUM OVER计算百分比分布-SQL-PHP中文网

核心是分子用SUM(col) OVER (ORDER BY x)算累积和，分母用SUM(col) OVER ()得固定总和，需防NULL、除零及整数截断。

sql如何实现累计占比统计_sum over计算百分比分布

用 `SUM() OVER()` 算累计占比，核心是两步：先算累计和，再除以总和

直接写 SUM(col) OVER (ORDER BY x) 只能得到累计值，不是百分比。必须显式除以全量总和——而这个总和不能写成常量，得用窗口函数算出来，否则分组后会出错。

常见错误是写成 SUM(col) OVER (ORDER BY x) / SUM(col)，这会触发 MySQL 8.0+ 的“混合窗口与非窗口聚合”报错，或在 PostgreSQL 中隐式转为 GROUP BY 行为，结果错乱。

正确做法：用 SUM(col) OVER () 获取全局总和（不带 ORDER BY 和 PARTITION BY）
累计和用 SUM(col) OVER (ORDER BY order_col)，注意 ORDER BY 列必须有确定顺序（比如时间、ID），否则累计结果不稳定
如果数据有重复 order_col 值，MySQL 和 PostgreSQL 默认按“范围窗口（RANGE）”处理，可能导致同一排序值的多行共享相同累计值；需要精确到行，加 ROWS UNBOUNDED PRECEDING

MySQL 8.0+ 和 PostgreSQL 写法一致，但 SQLite 不支持窗口函数

SQLite 3.25+ 虽然支持 OVER，但直到 3.42 才完整支持 SUM() OVER()，旧版本会报 no such function: sum 或直接语法错误。别在 SQLite 上硬套。

PostgreSQL 和 MySQL 8.0+ 语法完全兼容，示例：

SELECT 
  category,
  amount,
  SUM(amount) OVER (ORDER BY category ROWS UNBOUNDED PRECEDING) AS cumsum,
  ROUND(
    SUM(amount) OVER (ORDER BY category ROWS UNBOUNDED PRECEDING) * 100.0 / 
    SUM(amount) OVER (), 2
  ) AS cum_pct
FROM sales;

注意 * 100.0：用 100 整数会导致整除截断（尤其在 PostgreSQL 中），结果全为 0。

GROUP BY 后要累计占比？必须先聚合再开窗

如果原始表是明细数据（如每笔订单），但你想按 product_id 汇总后再算品类累计占比，不能直接在明细上 OVER (PARTITION BY product_id) —— 那算的是每个产品内部的累计，不是品类维度的分布。

先用子查询或 CTE 汇总： SELECT product_id, SUM(sales) AS total_sales FROM orders GROUP BY product_id
再对汇总结果开窗：SUM(total_sales) OVER (ORDER BY total_sales DESC)
若需按销售排名倒序累计（如“前 N 个产品占多少”），ORDER BY total_sales DESC 是关键，顺序反了占比曲线就颠倒

NULL 值会让累计中断，必须提前处理

SUM() 窗口函数默认跳过 NULL，看起来没问题，但一旦 ORDER BY 列含 NULL，不同数据库行为不一：MySQL 把 NULL 排最前，PostgreSQL 排最后，导致累计起点错位。

更隐蔽的问题是，如果某行 amount 为 NULL，它不会参与累计，但后续行的累计值会“跳过”它——表面上数字连续，实际漏掉了该记录的权重。

稳妥做法：用 COALESCE(amount, 0) 显式转 0，确保每行都计入
如果业务上 NULL 代表“未发生”，那转 0 合理；如果代表“未知”，就得先定义语义，不能无脑填充
检查 ORDER BY 列是否含 NULL：加 WHERE order_col IS NOT NULL 或用 COALESCE(order_col, 'ZZZZ') 统一归位

累计占比看着简单，真正上线时最容易栽在 NULL 处理、排序列歧义、以及没意识到 SUM() OVER () 和普通 SUM() 在上下文中的求值时机差异。