percent_rank()返回0.0到1.0的相对排名比例，公式为(rank−1)/(total_rows−1)，非整数百分比；需手动×100并格式化才符合报表习惯。
PERCENT_RANK() 返回的是什么值，为什么不是整数百分比
PERCENT_RANK() 计算的是「当前行在分组内排序位置的相对排名比例」，公式为 (rank - 1) / (total_rows - 1)，结果范围是 0.0 到 1.0（含两端），不是直接乘100后的整数。比如 5 行数据中排第 2 的行，PERCENT_RANK() 是 (2-1)/(5-1) = 0.25，对应 25%，但函数本身不自动 ×100 或加 % 符号。
常见错误是直接写 SELECT PERCENT_RANK() OVER (...) FROM ... 后发现结果像 0.0000、0.2500，误以为出错——其实完全正常。需要手动转换才符合业务报表习惯：
SELECT score, ROUND(PERCENT_RANK() OVER (ORDER BY score) * 100, 2) AS percentile_rank_pct FROM exam_scores;
按分组计算百分比分布时，PARTITION BY 必须显式指定
如果想看「每个班级内学生成绩的相对分布」，必须用 PARTITION BY class_id，否则默认在整个结果集上计算，会把不同班级混在一起排名，失去业务意义。
- 错误写法（全局排名）：
PERCENT_RANK() OVER (ORDER BY score) - 正确写法（班级内排名）：
PERCENT_RANK() OVER (PARTITION BY class_id ORDER BY score) - 注意：ORDER BY 在窗口定义中不可省略，否则报错
Window 'w' requires an ORDER BY clause
另外，PARTITION BY 字段值为 NULL 会被归为同一组——若 class_id 允许为空，这些记录将共同构成一个隐式分组，可能干扰统计口径。
PERCENT_RANK() 和 CUME_DIST()、NTILE() 的核心区别在哪
三者都用于分布分析，但语义和计算逻辑完全不同，选错会导致业务解释错误：
-
PERCENT_RANK()：基于 rank（重复值同名次），首行固定为0.0，末行固定为1.0（只要总行数 > 1） -
CUME_DIST()：计算「小于等于当前值的行数占比」，首行 ≥ 1/总行数，末行恒为1.0 -
NTILE(4)：强行把数据等分为 4 桶（可能不均），返回桶编号1~4，不反映连续分布
例如成绩 [80, 85, 85, 92]：
-
PERCENT_RANK()→[0.0, 0.333, 0.333, 1.0]（两个 85 并列第 2，所以都是 (2−1)/(4−1)） -
CUME_DIST()→[0.25, 0.75, 0.75, 1.0]（前两个 85 覆盖了前 3 行，3/4=0.75）
做「Top 10% 学生筛选」不能用 NTILE(10)，而应写 PERCENT_RANK() OVER (...) >= 0.9，因为后者严格按比例截断，不受重复值或总数是否整除影响。
MySQL 8.0+ 才支持，低版本替代方案很受限
PERCENT_RANK() 是 MySQL 8.0 引入的窗口函数，5.7 及更早版本不识别，执行会报错 FUNCTION xxx.PERCENT_RANK does not exist。
没有真正等价的低版本写法，常见“模拟”方案都有硬伤：
- 用自连接 + COUNT 统计排名再手工算比例：性能差、无法处理大表、GROUP BY 边界模糊
- 用变量
@rank := @rank + 1：在复杂查询（含 JOIN、WHERE、LIMIT）中顺序不可靠，MySQL 5.7 官方已警告变量赋值顺序未定义 - 导出到应用层（Python/Java）排序后计算：增加 I/O 和内存压力，失去数据库内聚合优势
如果必须兼容老版本，建议优先评估升级 MySQL；若不可行，至少避免在事务中依赖该模拟结果——精度和一致性无法保证。
