PERCENT_RANK()按(r-1)/(n-1)计算，返回[0.0, 1.0]内值：首行恒为0.0，末行（n>1时）恒为1.0，并列值共享相同结果，单行返回NULL，且必须配合OVER子句使用。
PERCENT_RANK函数的计算逻辑和返回值范围
PERCENT_RANK() 不是简单地把行号除以总行数，而是按公式 (rank - 1) / (total_rows - 1) 计算，其中 rank 是该行在窗口内的 RANK() 值（即并列时取相同名次，后续跳号）。这意味着：第一行永远是 0.0，最后一行永远是 1.0，中间值严格落在 [0, 1) 区间内（注意不是闭区间）。
常见误解是以为它等价于 ROW_NUMBER() OVER (...)::float / COUNT(*) OVER ()，但后者会把最后一名算成 1.0，且不处理并列——实际结果偏差明显。
使用场景包括：用户成绩分档、销售员业绩分布分析、指标在群体中的相对位置评估。
必须配合WINDOW子句使用，不能单独写在SELECT列表里
PERCENT_RANK() 是一个窗口函数，没有 OVER 子句会直接报错：ERROR: window function PERCENT_RANK requires a window specification。它不能像普通聚合函数那样用在 GROUP BY 后，也不能在 WHERE 或 HAVING 中直接引用（因为窗口计算发生在这些子句之后）。
实操建议：
- 先写好
ORDER BY部分，比如按销售额降序排：PERCENT_RANK() OVER (ORDER BY sales DESC) - 如需分区计算（比如每部门独立排名），加
PARTITION BY dept_id，注意此时每个分区内首尾仍为0.0和1.0 - 避免在子查询外层直接
WHERE percentile > 0.9—— 应该用 CTE 或嵌套查询先算出百分位，再过滤
和RANK、DENSE_RANK、CUME_DIST的区别在哪
容易混淆的是这几个排名函数的语义差异：
-
RANK()：并列时占位（如 1,1,3），PERCENT_RANK()基于此计算，所以并列项得到相同百分比值 -
DENSE_RANK()：并列不占位（如 1,1,2），但PERCENT_RANK()不基于它，不能混用 -
CUME_DIST()：计算“≤当前值的行数占比”，结果范围是(0, 1]，首行可能大于0.0，末行恒为1.0 -
NTILE(100)：强行分桶，不是连续比例，会有大量重复值，也不反映真实累积分布
举例：4 行数据排序后值为 [10,20,20,30]，PERCENT_RANK() 返回 [0.0, 0.333, 0.333, 1.0]；而 CUME_DIST() 返回 [0.25, 0.75, 0.75, 1.0]。
NULL值怎么处理？ORDER BY里的NULLS FIRST/LAST会影响结果
PERCENT_RANK() 本身不单独处理 NULL，它的行为完全由 ORDER BY 子句决定。默认情况下，NULL 被视为最大值（即排在最后），所以如果字段含 NULL 且未显式声明顺序，它们会集中在末尾，导致 PERCENT_RANK() 出现多个 1.0（只要 NULL 行不是唯一末尾行）。
实操建议：
- 明确写
ORDER BY score DESC NULLS LAST或NULLS FIRST，避免依赖默认行为 - 若业务要求忽略
NULL行，先用WHERE score IS NOT NULL过滤，否则NULL行参与计数和排序，会拉低其他行的百分比 - 测试时故意插入几条
NULL数据，观察返回值是否符合预期，这是最容易被忽略的验证点
实际应用中，最常出问题的是把 PERCENT_RANK() 当作“前10%”筛选工具直接用，却没意识到它对 NULL 敏感、不能在 WHERE 里直用、且并列逻辑和业务理解不一致——这些细节不提前确认，跑出来的报表可能全盘偏移。
