percent_rank()返回0.0–1.0浮点数，表示“比当前行小的记录占比”，计算公式为(rank−1)/(总行数−1)，首行恒为0.0、末行（组内≥2行）恒为1.0，单行组返回null。
PERCENT_RANK() 的返回值到底代表什么
PERCENT_RANK() 不是“该分值高于多少百分比的记录”，而是“比它小的记录占比”。它的计算逻辑是：(rank - 1) / (总行数 - 1)，其中 rank 是按 ORDER BY 列升序排列后的不跳过并列的排名（即 RANK() 值）。所以最小值永远是 0.0，最大值永远是 1.0（除非全表只有一行，此时为 0.0）。
常见误解是把它当成「超过多少人」的直观百分比——比如结果 0.75，实际意思是“有 75% 的记录严格小于当前行”，而不是“排在前 25%”。这点直接影响业务解读，尤其在做绩效分段或阈值告警时。
必须搭配 WINDOW 子句，不能直接用在 WHERE 或 GROUP BY 中
PERCENT_RANK() 是窗口函数，只能出现在 SELECT 列表或 ORDER BY 子句中，不能用于过滤或聚合上下文。试图写成 WHERE PERCENT_RANK() > 0.9 会报错 ERROR: window functions are not allowed in WHERE。
正确做法是用子查询或 CTE 先算出排名，再过滤：
SELECT score, pct_rank FROM ( SELECT score, PERCENT_RANK() OVER (ORDER BY score) AS pct_rank FROM exam_results ) t WHERE pct_rank >= 0.9;
- 注意：如果需要按科目分组计算排名，得用
PARTITION BY subject，否则默认全表一个窗口 -
ORDER BY必须明确指定方向；默认 ASC，若用DESC，则最高分变成0.0，容易反直觉 - NULL 值默认排在最前（ASC）或最后（DESC），会影响分母和分子，建议提前
WHERE score IS NOT NULL
和 CUME_DIST()、NTILE() 的关键区别在哪
三者都做分布类计算，但语义不同，选错会导致业务逻辑偏差：
-
PERCENT_RANK()：基于排名位置，两端固定为0.0和1.0，中间呈线性分布；对并列值返回相同结果（因为 rank 相同） -
CUME_DIST()：返回“小于等于当前值的行数占比”，所以最小值不是0.0，而是出现次数 / 总数；最大值恒为1.0 -
NTILE(4)：强行把数据等分成 4 组（可能不均），只返回整数桶号（1–4），不提供连续百分比
例如 5 行分数 [60,70,70,80,90]，两个 70 的 PERCENT_RANK() 都是 (2-1)/(5-1)=0.25；而 CUME_DIST() 对 70 是 3/5=0.6（因含两个 70 和一个 60）。
ORDER BY 列有重复值时，PERCENT_RANK() 的行为很稳定，但别误读“并列”
当多个记录值相同时，PERCENT_RANK() 会给出完全相同的值——这不是 bug，是设计使然。它反映的是“这些记录共享同一个 rank 位置”，所以分子一致。
但要注意：如果你后续想用这个值做分段（比如 top 10%），直接 >= 0.9 可能漏掉一批并列高分者，也可能多抓一批。真实场景中更稳妥的做法是结合 RANK() 或 DENSE_RANK() 做二次判断：
SELECT score,
PERCENT_RANK() OVER (ORDER BY score) AS pct,
RANK() OVER (ORDER BY score DESC) AS rnk
FROM exam_results;
真正卡位时，用 rnk 比硬套 <code>pct >= 0.9 更可控。
另外，PostgreSQL 和 SQL Server 行为一致，但 MySQL 8.0+ 才支持；SQLite 不支持，别在移动端 SQLite 环境里试。
