分组内累计占比需手动组合窗口函数实现，不能直接用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_pct FROM 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_pct
FROM 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，这是浮点运算和四舍五入共同导致的，别当成逻辑错误。
