在SQL中如何计算分组后的累计百分比分布情况

分组内累计占比需手动组合窗口函数实现，不能直接用PERCENT_RANK()或CUME_DIST()；核心是用ROW_NUMBER() OVER(PARTITION BY...ORDER BY...)编号，COUNT(*) OVER(PARTITION BY...)算分母，再计算百分比。

用 ROW_NUMBER() 和 COUNT(*) 手动算累计占比

直接用 PERCENT_RANK() 或 CUME_DIST() 看似方便，但它们默认按整个结果集排序计算，不是「分组内」的累计百分比。真要按分组（比如每个 category 单独算从低到高的累计占比），得自己组合窗口函数。

核心思路：先按组排序并编号，再用组内总行数做分母。示例语句：

SELECT   category,  value,  ROW_NUMBER() OVER (PARTITION BY category ORDER BY value) AS rn,  COUNT(*) OVER (PARTITION BY category) AS total_in_group,  ROUND(100.0 * ROW_NUMBER() OVER (PARTITION BY category ORDER BY value) / COUNT(*) OVER (PARTITION BY category), 2) AS cum_pctFROM sales;

注意点：

• ROW_NUMBER() 从 1 开始编号，所以第一个值占比是 100.0 / total_in_group，不是 0%
• 如果存在相同 value，ROW_NUMBER() 会强制分配不同序号，导致同值不同占比；想让同值共享同一累计比例，改用 RANK()，但需同步调整分子逻辑
• 分母必须用 COUNT(*) OVER (PARTITION BY ...)，不能用子查询或关联，否则无法对齐窗口范围

当需要「等于或小于当前值」的累计占比时，用 SUM() OVER 配合布尔转整数

上面方法只算「排在当前行及之前的位置占比」，但业务常要的是「值 ≤ 当前行 value 的记录占组内多少百分比」——比如统计「价格 ≤ 当前商品价格的销量占比」。

这时不能依赖排序序号，得统计满足条件的行数：

SELECT   category,  price,  SUM(CASE WHEN price <= t1.price THEN 1 ELSE 0 END)     OVER (PARTITION BY category ORDER BY price ROWS UNBOUNDED PRECEDING) AS cum_count,  COUNT(*) OVER (PARTITION BY category) AS total,  ROUND(100.0 * SUM(CASE WHEN price <= t1.price THEN 1 ELSE 0 END)     OVER (PARTITION BY category ORDER BY price ROWS UNBOUNDED PRECEDING) / COUNT(*) OVER (PARTITION BY category), 2) AS cum_pctFROM products t1;

关键细节：

• ROWS UNBOUNDED PRECEDING 是必须的，否则默认 RANGE 模式在相同 price 下会重复累加，结果偏高
• CASE WHEN ... THEN 1 ELSE 0 把布尔判断转为可累加数值，比子查询高效得多
• ORDER BY 必须明确，且字段要和 CASE 中的比较字段一致，否则窗口范围不可控

CUME_DIST() 的真实行为与适用边界

CUME_DIST() 返回「小于等于当前行值的行数 / 总行数」，听起来正符合需求，但它不支持 PARTITION BY 后再按组内排序计算——等等，其实支持。问题在于很多人误写成：

-- ❌ 错误：没写 ORDER BY，CUME_DIST 无意义CUME_DIST() OVER (PARTITION BY category)

正确写法必须带 ORDER BY：

-- ✅ 正确：按组内 price 排序后计算累计分布CUME_DIST() OVER (PARTITION BY category ORDER BY price)

但要注意：

• 它对相同 price 的所有行返回相同值（例如三个并列第2名，都返回 3/10 = 0.3），而 ROW_NUMBER() 方案中它们会得到 2/10、3/10、4/10
• 它天然包含「等于当前值」的逻辑，省去手动 CASE，但无法控制是否去重或跳过空值
• 某些旧版 PostgreSQL（CUME_DIST()，得退回手动方案

NULL 值和排序方向对累计占比的影响

默认排序把 NULL 排在最前（ORDER BY value），若业务要求 NULL 当作最大值或忽略，必须显式声明：

• 把 NULL 排最后：ORDER BY value NULLS LAST
• 完全排除 NULL 行：WHERE value IS NOT NULL（推荐，避免干扰分母计数）
• 升序（ASC）对应「从小到大累计」，降序（DESC）则变成「从大到小累计」，别反了业务含义

另外，ROUND() 的精度取舍会影响展示一致性——比如 ROUND(99.999, 2) 得到 100.00，但实际分母除不尽时，各组最后一行未必正好是 100，这是浮点运算和四舍五入共同导致的，别当成逻辑错误。