PERCENT_RANK 是返回相对排名比例的窗口函数，计算公式为(rank-1)/(total_rows-1)，最小值为0、最大值为1，不等同于统计学中的百分位数。
PERCENT_RANK 是什么，它和你想要的“百分位”可能不一样
PERCENT_RANK 返回的是「相对排名比例」，不是统计学中常说的第 p 百分位（如 P90）。它的计算逻辑是：(rank - 1) / (total_rows - 1)，其中 rank 是按 ORDER BY 排序后的行号（从 1 开始），且相同值共享后续最小 rank（即跳过并列后的位置）。这意味着：最小值永远是 0，最大值永远是 1，中间值均匀分布在 [0,1) 区间内——但它不保证恰好有 10% 的人 ≤ P10 的结果。
如果你真正需要「成绩不低于前 10% 学生」这类业务语义，PERCENT_RANK 往往不够用，更推荐用 PERCENTILE_CONT 或窗口 + COUNT 手动算。
正确写法：用 OVER() 定义排序范围，不能漏掉 ORDER BY
常见错误是直接写 PERCENT_RANK() 不带 OVER，这会报错；或写了 OVER() 却没写 ORDER BY，导致结果全为 0（因为默认按无序分组，每组只有一行）。
- ✅ 正确：按成绩降序排，高分在前，对应更高百分位数值（更接近 1）：
SELECT name, score, PERCENT_RANK() OVER (ORDER BY score DESC) AS pct_rank FROM students;
- ❌ 错误：缺少
ORDER BY：PERCENT_RANK() OVER () - ⚠️ 注意：如果表中有重复分数（比如 5 人同得 92 分），他们将获得相同的
rank值，因此PERCENT_RANK结果也完全相同——这是设计行为，不是 bug。
和 RANK()/DENSE_RANK() 混用时，别假设顺序一致
PERCENT_RANK 依赖底层 RANK()（不是 DENSE_RANK()）来算分子。所以当你同时查三者时，会发现：RANK() 和 PERCENT_RANK() 的分组边界严格对齐，但 DENSE_RANK() 的编号更紧凑，数值不匹配。
例如成绩 [100, 95, 95, 90]：
score | RANK | DENSE_RANK | PERCENT_RANK 100 | 1 | 1 | 0.0 95 | 2 | 2 | 0.333... 95 | 2 | 2 | 0.333... 90 | 4 | 3 | 1.0
看到没？PERCENT_RANK 的第三行不是 0.666…，因为分母是 4-1 = 3，分子是 4-1 = 3 → 3/3 = 1.0。这里容易误读成“90 分排最后所以是 100%”，其实它只是数学定义的结果。
想按班级分别算百分位？PARTITION BY 是必须的
如果不加 PARTITION BY class_id，整个表一起排序，跨班比较就失去意义——比如高三(1)班平均分 85，高三(2)班平均分 92，强行混排会让(1)班高分学生被压到中下游。
- ✅ 按班级独立计算：
PERCENT_RANK() OVER (PARTITION BY class_id ORDER BY score DESC)
- ⚠️ 注意：
PARTITION BY后不能再用聚合函数（如AVG(score)）在同一个OVER里，否则语法报错。需要先聚合再 JOIN，或用子查询。 - ? 小技巧：如果想排除缺考（score IS NULL）的学生参与排名，WHERE 过滤比在
OVER里处理更可靠——因为NULLS FIRST/LAST在不同数据库中行为不一，而 WHERE 能彻底移除干扰行。
实际业务中，最常被忽略的是：把 PERCENT_RANK = 0.9 直接当成「前 10%」来筛选学生。它只表示「有 90% 的人成绩 ≤ 该生」，但因并列、数据分布偏斜，真实覆盖人数可能远超或不足 10%。真要卡比例，得用 NTILE(10) 或 PERCENTILE_CONT(0.9) 配合过滤。
