PERCENT_RANK 返回0到1之间的值，因其计算公式为(rank-1)/(total_rows-1)，首行恒为0、末行恒为1；单行时按标准返回0.0，本质是归一化位置占比而非人数比例。
PERCENT_RANK 为什么返回 0 和 1 之间的值？
PERCENT_RANK 不是简单排名，而是计算「当前行在分组内的相对位置」：它把排序后的行看作等距点，用 (rank - 1) / (total_rows - 1) 公式算出归一化比例。所以首行一定是 0（1-1 除以任何正数），末行一定是 1（只要总行数 > 1）。如果只有一行，PERCENT_RANK 返回 0.0（分母为 0，SQL 标准定义为 0）。
常见误解是把它当「前多少百分比的人不如我」，实际它更接近「我在有序队列中的位置占比」——类似刻度尺上的读数，不是人数统计。
按销售员分组计算时必须用 PARTITION BY
直接对全表用 PERCENT_RANK() OVER (ORDER BY sales_amount) 会把所有销售员混在一起排，失去个体对比意义。真实场景中，你通常想看「张三在华东区团队里排第几百分位」或「李四在 2024 年 Q2 的业绩处于什么水平」。
正确写法必须显式分区：
SELECT
name,
region,
sales_amount,
PERCENT_RANK() OVER (
PARTITION BY region
ORDER BY sales_amount DESC
) AS pr_rank
FROM sales;-
PARTITION BY region确保每个大区独立计算，互不干扰 -
ORDER BY sales_amount DESC保证高业绩排前面，百分比数值越大代表业绩越好 - 若漏掉
PARTITION BY，所有人的pr_rank都基于全局排序，区域间差异被抹平
和 RANK、DENSE_RANK 混用时要注意空洞问题
PERCENT_RANK 对重复值的处理方式与 RANK 一致：相同销售额得到相同排名，但会跳过后续名次。这直接影响分母 (total_rows - 1) 的取值——它始终是窗口内总行数减一，不管有没有并列。
例如某区域有 5 人，其中两人并列第 1，则 RANK 结果为 [1,1,3,4,5]，而 PERCENT_RANK 的分母仍是 5-1 = 4，对应结果为 [0.0, 0.0, 0.75, 0.9, 1.0]。
- 不要指望
PERCENT_RANK = 0.5表示「超过一半人」；它只表示「位置在排序序列中点」 - 若需「超过 X% 销售员」这类业务口径，应改用
COUNT(*) FILTER (WHERE sales_amount > current)手动算比例 - Oracle/PostgreSQL 支持
PERCENT_RANK，MySQL 8.0+ 才支持，旧版 MySQL 需用变量模拟
ORDER BY 中 NULL 值会让结果不可控
默认情况下，NULL 在 ORDER BY 中排最前（ASC）或最后（DESC），取决于数据库实现和 NULLS FIRST/LAST 设置。而 PERCENT_RANK 会把 NULL 当作有效值参与排序和计数，导致：明明只有 4 条非空数据，却因 1 个 NULL 占位，分母变成 5-1 = 4，扭曲整体分布。
- 务必在
ORDER BY显式控制 NULL：如ORDER BY sales_amount DESC NULLS LAST - 更稳妥做法是提前过滤：
WHERE sales_amount IS NOT NULL - 某些数据库（如 SQL Server）不支持
NULLS FIRST/LAST，只能靠CASE WHEN把 NULL 映射到极小/极大值来人工排序
真正麻烦的是业务方把 PERCENT_RANK = 0.0 理解成「垫底」，而实际上它可能只是「数据缺失」——这个边界含义，文档很少写清楚，但上线后最容易被质疑。
