SQL查询如何计算分组内的累积分布：使用CUME_DIST函数分析
什么是CUME_DIST，它和PERCENT_RANK有什么区别
简单来说，CUME_DIST回答的问题是：在同一个分组里，有多少比例的数据是小于或等于当前这个值的？它的计算结果范围在 (0, 1] 之间，哪怕你排第一，结果也是 1/n，永远不会是零。而且，它非常“公平”——遇到数值完全相同的行，会给它们相同的累积分布值。
相比之下，PERCENT_RANK的算法就不同了。它依据的是排名位置，公式是 (排名-1)/(总行数-1)。这就导致了两个特点：第一名永远是0，最后一名永远是1；而且，如果出现并列情况，它会跳过后续排名。比如两个并列第二，下一个就直接是第四了，中间会留下空档。所以，当你需要严格评估“有多少数据没超过当前水平”时，CUME_DIST才是正确的选择。
这里有几个新手常踩的坑：一是忘了加PARTITION BY，结果把整张表当成一个组来计算，完全失去了分组分析的意义；二是误以为函数直接输出百分比，其实它返回的是小数，需要自己乘以100并四舍五入。
怎么正确写分组内的CUME_DIST窗口函数
关键在于OVER子句的写法，必须同时明确PARTITION BY和ORDER BY。前者负责划清界限，比如按部门、班级进行分组，让计算在组内独立进行；后者决定累积的方向，通常是升序排列，这样累积分布就从低到高逐渐增加。
- 分组是前提：
PARTITION BY必须写清楚，否则就是全局计算，谈不上“分组内”。 - 注意NULL值：排序列如果存在NULL，这些行会被归到累积分布最小的一端。不过，不同数据库对NULL的排序默认规则不同（PostgreSQL放最前，MySQL 8.0放最后），这点要留意。
- 顺序可调整：如果你想看“高分段”的占比，用
ORDER BY salary DESC降序排列即可，此时最高薪员工的累积分布就是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：行为最符合标准，相同值得到相同结果；对于
PARTITION BY字段为NULL的行，它们会自成一组。 - SQL Server：在排序时，默认将NULL值放在最后（NULLS LAST），而PostgreSQL默认放在最前（NULLS FIRST）。如果业务上需要统一，在PostgreSQL中可以显式写
ORDER BY salary ASC NULLS LAST，但SQL Server不支持此语法，得用CASE WHEN语句来模拟。 - 避坑指南：SQLite不支持这个函数，直接别考虑。旧版MySQL会报“FUNCTION xxx does not exist”错误。Oracle虽然支持，但有个特殊要求：窗口函数必须赋予一个别名，否则会语法报错。
为什么CUME_DIST结果里没有0，但PERCENT_RANK有
这是由两者的根本定义决定的。CUME_DIST计算的是“小于等于当前值的行数”除以“总行数”。既然当前行自己肯定满足“小于等于”的条件，分子至少为1，所以结果最小也是 1/n，自然没有0。
而PERCENT_RANK的公式是 (排名-1)/(总行数-1)，排名第一时，分子为0，结果就是0。
这个区别有实际影响。当你需要定位“最低一档”的数据，或者设置一个阈值（比如定义累积分布≤0.1的用户为新客）时，CUME_DIST能确保把最小值那批数据包含进来，不会遗漏。但如果你非要把它的起点对齐到0，就得自己额外写逻辑，通常不建议这么做。
还有一个容易混淆的地方：用CUME_DIST做筛选时，写WHERE cume_dist <= 0.25，得到的并不是通常理解的“前25%”的数据，而是“累计占比不超过25%”的那些数值。在数据分布不均匀的情况下，这可能只对应前几行数据。如果你真想找四分位数，应该使用PERCENTILE_CONT(0.25)或者NTILE(4)这类专门的分位函数。
