CUME_DIST比PERCENT_RANK更适合初筛异常分组，因其返回“≤当前值的行数/组内总行数”，结果范围(0,1]且对重复值稳定连续；而PERCENT_RANK依赖排名公式(rank−1)/(rows−1)，首行为0、易受排序抖动影响，边界识别不如CUME_DIST鲁棒。
为什么 CUME_DIST 比 PERCENT_RANK 更适合初筛异常分组
CUME_DIST 返回的是“小于等于当前值的行占组内总行数的比例”，结果范围是 (0, 1]，且对重复值天然去重敏感——相同值会得到相同累积比例，但跳过后续重复项时不会中断连续性。这比 PERCENT_RANK 在处理大量重复异常值（比如一批 status = 'error' 的固定日志）时更稳定，不容易因排序抖动漏掉边界点。
它不依赖均值或标准差，也不需要预计算四分位数，只要数据可排序、有业务意义的量纲（如响应时间、金额、数量），就能直接跑出分布位置。适合在还没确定用 IQR 还是 Z-score 前，先快速看一眼“尾巴有多长”。
- 必须配合
ORDER BY使用，否则报错：ERROR: window function cume_dist requires an ORDER BY clause - 不能单独用于过滤，需嵌套在子查询或 CTE 中，因为窗口函数不能出现在
HAVING或WHERE里 - 对 NULL 默认排在最前，若业务中 NULL 表示“未上报”，应先用
WHERE col IS NOT NULL预过滤，否则CUME_DIST会把所有 NULL 算作“最小值”，扭曲整体分布
怎么写一个能直接标出 Top 5% 异常记录的查询
核心是用 CUME_DIST() 计算每行在其分组内的累积占比，再用外层过滤 cume_dist > 0.95。注意不是 >= 0.95 —— 因为 CUME_DIST 对重复值返回相同值，用 > 才能确保只取真正落在尾部的那批，避免把中间一堆并列第 95 名全捞出来。
示例：查每个 service_name 下响应时间最长的前 5% 请求
SELECT service_name, request_id, duration_ms
FROM (
SELECT service_name,
request_id,
duration_ms,
CUME_DIST() OVER (PARTITION BY service_name ORDER BY duration_ms) AS cume_dist
FROM api_logs
WHERE duration_ms IS NOT NULL
AND duration_ms > 0
) t
WHERE cume_dist > 0.95;-
PARTITION BY service_name是分组依据，别漏写，否则全表当一组算 - 排序字段
duration_ms必须和业务异常定义一致：高值异常就升序？错，得ORDER BY duration_ms（升序）→ 尾部才是最大值；想抓最小值异常（如负耗时），才用ORDER BY duration_ms DESC - 没加
WHERE duration_ms > 0可能引入测试数据或脏数据，让CUME_DIST的 0.95 分界线漂移
CUME_DIST 和 IQR 法混用时最容易踩的坑
有人想“先用 CUME_DIST 快速捞出疑似异常，再对这批结果跑 IQR”，这逻辑看似合理，实则危险：IQR 本身需要基于完整分组数据计算 Q1/Q3，如果只在 cume_dist > 0.95 的子集上算，Q3 就变成了子集里的 75% 位，完全失真。
正确做法是：用 CUME_DIST 当探针，确认某组确实存在长尾 → 再回过头，用窗口函数预计算该组的 PERCENTILE_CONT(0.25) 和 PERCENTILE_CONT(0.75) → 最后用 IQR = Q3 - Q1 和 upper_bound = Q3 + 1.5 * IQR 做硬过滤。
-
PERCENTILE_CONT要求ORDER BY不可省略，且类型必须支持排序（比如 text 类型不能直接用于数值百分位） - MySQL 不支持
PERCENTILE_CONT，若需跨库兼容，得用ROW_NUMBER() / COUNT(*)手动逼近，但精度下降 -
CUME_DIST结果是浮点数，比较时别用= 0.95，一律用>或
当 CUME_DIST 返回全是 1.0 怎么办
这是最常被忽略的信号：说明组内所有值完全相同，或者只有极少数不同值（比如 100 条记录里 99 条是 200ms，1 条是 201ms）。此时 CUME_DIST 对最大值返回 1.0，其余也全为 1.0（因为“≤201ms”的行占 100%）。
这不是函数坏了，而是数据本身缺乏变异。这时候强行标“Top 5%”毫无意义，应转而检查：
- 该分组是否本就不该有波动？比如配置类表的
version字段，全一致反而是健康的 - 是否漏了关键维度？比如没按
region或client_type细分，导致高延迟和低延迟混在一起拉平了分布 - 原始数据精度是否丢失？
duration_ms被 round 到秒级，所有值都变成整数，自然失去区分度
遇到这种情况，CUME_DIST 就该停用，换用 COUNT(DISTINCT col) 先确认组内离散程度，再决定下一步策略。
