SQL查询如何计算分组内的累积分布_使用CUME

CUME_DIST返回分组内≤当前值的行数占比，范围(0,1]且不跳过重复值；PERCENT_RANK按(排名-1)/(总行数-1)计算，首尾固定为0/1且遇重复值跳排名。

sql查询如何计算分组内的累积分布_使用cume_dist函数分析

什么是`CUME_DIST`，它和`PERCENT_RANK`有什么区别

CUME_DIST返回当前行在分组内「小于等于该行值的行数」占总行数的比例，结果范围是 (0, 1]，且最小值一定 > 0（哪怕排第一，也是 1/n）。它不跳过重复值——相同值的行会得到完全相同的累积分布值。

而 PERCENT_RANK 是按「排名位置减1除以总行数减1」算的，首行一定是 0，末行一定是 1；遇到重复值时，会跳过后续排名（比如两个并列第2，下一个是第4），导致中间出现空档。如果你要严格反映「有多少比例的数据 ≤ 当前值」，必须用 CUME_DIST。

常见错误现象：CUME_DIST() OVER (ORDER BY score) 忘记加 PARTITION BY 导致全表计算，而不是按班级/部门等分组；或者误以为它能直接输出百分比（实际是小数，需 ×100 并 ROUND）。

怎么正确写分组内的`CUME_DIST`窗口函数

关键在于 OVER 子句中同时指定 PARTITION BY 和 ORDER BY。前者切分逻辑组（如每个department独立计算），后者决定累积方向（通常升序：低分在前，累积分布从小到大）。

PARTITION BY 必须明确，否则就是全表累积，失去“分组内”意义
ORDER BY 列不能为 NULL，否则这些行会被归到累积分布最小的一批（不同数据库处理略有差异，PostgreSQL 把 NULL 排最前，MySQL 8.0 默认排最后）
如果想按降序看「高分占比」，写 ORDER BY salary DESC，此时最高薪员工的 CUME_DIST = 1.0
结果是 DECIMAL 或 FLOAT，建议显式 ROUND(cume_dist, 4) 避免浮点误差干扰阅读

示例（查每个部门薪资的累积分布）：

SELECT 
  name, 
  department, 
  salary,
  ROUND(CUME_DIST() OVER (PARTITION BY department ORDER BY salary), 4) AS cume_dist
FROM employees;

`CUME_DIST`在MySQL 8.0+、PostgreSQL、SQL Server中的兼容性注意点

所有主流新版数据库都支持 CUME_DIST，但细节行为有差异：

MySQL 8.0+ 和 PostgreSQL 完全符合标准：相同值 → 相同 CUME_DIST 值；PARTITION BY 空值会被单独分组（即 department IS NULL 的人自成一组）
SQL Server 对 NULL 的 ORDER BY 默认行为是 NULLS LAST，而 PostgreSQL 默认 NULLS FIRST；若业务要求一致，显式写 ORDER BY salary ASC NULLS LAST（PostgreSQL 支持，SQL Server 不支持该语法，得用 CASE 替代）
SQLite 不支持 CUME_DIST，别踩坑；旧版 MySQL（FUNCTION xxx does not exist
Oracle 虽支持，但窗口函数必须带别名（CUME_DIST() OVER (...) AS cd），否则语法报错

为什么`CUME_DIST`结果里没有0，但`PERCENT_RANK`有

这是定义决定的：CUME_DIST 计算的是「≤ 当前行值的行数 / 总行数」，只要有一行满足条件（即它自己），分子至少为 1，所以结果最小是 1.0 / n。而 PERCENT_RANK 公式是 (rank - 1) / (n - 1)，首行 rank=1 → 结果=0。

这意味着：当你需要识别「最低一档占比」或做阈值切分（比如取累积分布 ≤ 0.1 的用户为新客）时，CUME_DIST 天然不会漏掉最小值；但如果你硬要对齐 PERCENT_RANK 的 0 起始，只能自己补逻辑（不推荐）。

容易被忽略的地方：用 CUME_DIST 做分位点筛选时，别写 WHERE cume_dist 就认为是「前25%」——它其实是「累计占比 ≤ 25% 的那些值」，可能只覆盖前几行（尤其数据分布不均时）。真要取四分位数，该用 PERCENTILE_CONT(0.25) 或 NTILE(4)。