CUME_DIST返回分组内≤当前值的行数占比，范围(0,1]且不跳过重复值；PERCENT_RANK按(排名-1)/(总行数-1)计算，首尾固定为0/1且遇重复值跳排名。
什么是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% 的那些值」，可能只覆盖前几行（尤其数据分布不均时）。真要取四分位数，该用 <code>PERCENTILE_CONT(0.25) 或 NTILE(4)。
