cume_dist适合回答“有多少比例的数据 ≤ 当前值”，它返回当前行值在分组内小于等于该值的行数占比，范围(0,1]，必须配合order by使用，重复值共享同一结果，null默认参与计算且排最前。
直接回答：CUME_DIST适合回答“有多少比例的数据 ≤ 当前值”
它不是用来找第90百分位点，也不是算相对排名，而是给出一个明确的覆盖比例——比如某客户销售额对应的CUME_DIST是0.83，就表示全组里有83%的客户销售额 ≤ 他。这个语义清晰、边界确定，特别适合做分层归类、阈值筛选和分布描述。
CUME_DIST()必须写ORDER BY，否则报错
所有主流支持它的数据库（SQL Server、PostgreSQL、MySQL 8.0+、Oracle、BigQuery）都强制要求ORDER BY子句。漏掉会直接失败：
- PostgreSQL 报
window function call requires window definition - SQL Server 报
Incorrect syntax near ')' - MySQL 8.0+ 报
Window function 'CUME_DIST' requires an ORDER BY clause
注意：PARTITION BY可选，但ORDER BY不可省；也不能只写PARTITION BY而没ORDER BY。
重复值会让CUME_DIST结果“跳变”，不是线性增长
遇到相同值，CUME_DIST()把它们全部算进分子，导致结果非均匀分布。例如数据[100, 200, 200, 200, 300]，计算结果是：
-
100 → 0.2（1/5） -
200 → 0.8（4/5，含三个200） -
300 → 1.0（5/5）
这意味着：
- 不能靠
CUME_DIST = 0.1去精确匹配“前10%”，因为0.1可能根本不出现在结果中 - 若需等距分段（如每10%一段），应改用
NTILE(10)或手动结合ROW_NUMBER() - 业务上接受“并列即同档”时，这种跳变反而是优点——它真实反映值域覆盖度
空值（NULL）默认参与计算，且排在最前
CUME_DIST()默认把NULL当最小值处理（PostgreSQL/SQL Server/Oracle 均如此），所以第一个非空值的累积比例会偏高。例如5行中有2个NULL，再跟[100, 200, 300]，那么100的CUME_DIST就是3/5 = 0.6，而非1/3 ≈ 0.33。
安全做法是显式过滤或控制排序位置：
- 过滤：
WHERE sales IS NOT NULL - 排最后（PostgreSQL/Oracle 支持）：
ORDER BY sales NULLS LAST - MySQL 8.0+ 不支持
NULLS LAST，只能靠WHERE预处理
真正容易被忽略的是：当你用CUME_DIST()筛选“前20%高价值客户”时，如果原始数据含大量NULL销售记录，又没提前过滤，结果会把很多低值客户错误纳入前20%——因为分母被拉大，分子却只算到非空部分的覆盖。
