cume_dist()返回当前行值在分组内“≤该值”的行数占比，范围(0,1]且最小值>0；percent_rank()按(rank-1)/(total-1)计算，首行为0、末行未必为1；前者适合“多少比例≤当前值”，后者反映相对排名位置。
什么是 CUME_DIST()，它和 PERCENT_RANK() 有什么区别？
CUME_DIST() 返回当前行在分组内「小于等于该行值」的行数占比，结果范围是 (0, 1]，且最小值一定大于 0（因为至少包含自己）。而 PERCENT_RANK() 是基于排名计算的相对位置，公式为 (rank - 1) / (total_rows - 1)，首行结果恒为 0，末行不一定为 1。
常见错误是把两者混用：比如想看“某销售额排在前 30% 的位置”，误用 PERCENT_RANK() 会导致边界值判断偏差——CUME_DIST() 更适合回答“有多少比例的数据 ≤ 当前值”。
CUME_DIST() 必须配合 ORDER BY 和窗口定义使用
不写 ORDER BY 会报错（如 PostgreSQL 报错 window function requires an ORDER BY clause），且不能只写 PARTITION BY 而省略排序。实际写法必须是：
SELECT sales, CUME_DIST() OVER (ORDER BY sales) AS cume_dist FROM orders;
如果你要按部门分别计算累积分布，得这么写：
SELECT dept, sales, CUME_DIST() OVER (PARTITION BY dept ORDER BY sales) AS cume_dist FROM orders;
注意：PARTITION BY 会重置计数，每个分区独立算累积比例；没加 PARTITION BY 就是全表统一排序后计算。
处理重复值时 CUME_DIST() 的行为很关键
遇到相同 sales 值，CUME_DIST() 把它们视为同一层级，结果相同，且分子是「≤ 当前值的所有行数」。例如数据 [100, 200, 200, 300]：
- 100 →
CUME_DIST = 1/4 = 0.25 - 200 →
CUME_DIST = 3/4 = 0.75（含两个 200） - 300 →
CUME_DIST = 4/4 = 1.0
这和 RANK() 或 DENSE_RANK() 的逻辑不同，别指望它返回“去重后的比例”。如果业务要求按唯一值归一化，得先用子查询去重再算。
不同数据库对 CUME_DIST() 的支持与精度差异
- PostgreSQL、SQL Server、Oracle、Snowflake、BigQuery 都支持标准语法
- MySQL 8.0+ 支持，但早期版本（如 5.7）完全不支持，强行用会报错
FUNCTION database.CUME_DIST does not exist
- SQLite 不支持窗口函数，自然没有
CUME_DIST()
- 结果默认是
double 或 numeric 类型，但有些引擎（如旧版 Presto）可能返回浮点误差，比如 0.999999999 而非精确 1.0，做等值判断时建议用 >= 0.999 而非 == 1.0
FUNCTION database.CUME_DIST does not exist CUME_DIST() double 或 numeric 类型，但有些引擎（如旧版 Presto）可能返回浮点误差，比如 0.999999999 而非精确 1.0，做等值判断时建议用 >= 0.999 而非 == 1.0
真正容易被忽略的是：当你用 CUME_DIST() 做分位筛选（比如取前 10%）时，由于它是「≤ 当前值的比例」，实际拿到的行数可能略多于预期——尤其在尾部存在大量重复值时。得结合 ROW_NUMBER() 或业务规则二次截断。
