分组内累计占比需手动组合窗口函数实现,不能直接用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 把布尔判断转为可累加数值,比子查询高效得多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/10CASE,但无法控制是否去重或跳过空值默认排序把 NULL 排在最前(ORDER BY value),若业务要求 NULL 当作最大值或忽略,必须显式声明:
ORDER BY value NULLS LAST
WHERE value IS NOT NULL(推荐,避免干扰分母计数)ASC)对应「从小到大累计」,降序(DESC)则变成「从大到小累计」,别反了业务含义另外,ROUND() 的精度取舍会影响展示一致性——比如 ROUND(99.999, 2) 得到 100.00,但实际分母除不尽时,各组最后一行未必正好是 100,这是浮点运算和四舍五入共同导致的,别当成逻辑错误。