percent_rank() 返回当前行在分组内排序后的相对位置（0到1之间），按公式(rank-1)/(total_rows-1)计算，首行为0.0、末行为1.0；需配合order by使用，可加partition by分组，null影响分母，小样本下分辨率低。
PERCENT_RANK() 函数怎么用才对
PERCENT_RANK() 是窗口函数，返回当前行在分组内排序后的相对位置（0 到 1 之间），**不是四舍五入后的整数百分比**。它按公式 (rank - 1) / (total_rows - 1) 计算，所以首行永远是 0.0，末行永远是 1.0（除非只有一行，此时为 0.0）。
常见错误是直接乘以 100 后加 % 符号就以为是“第几名的百分比”，其实它反映的是“比多少比例的人低”。比如 PERCENT_RANK() 得到 0.75，意思是该销售员业绩高于 75% 的同行，而非排在前 25%。
- 必须配合
ORDER BY使用，否则报错：PERCENT_RANK() OVER (ORDER BY sales_amount DESC) - 如果要按地区分组排名，加
PARTITION BY region，否则全表统一排序 - NULL 值默认排在最前（
ASC）或最后（DESC），影响分母计数，建议提前用WHERE sales_amount IS NOT NULL过滤
和 CUME_DIST()、NTILE() 的关键区别在哪
三者都用于分布分析，但语义和用途不同：
-
CUME_DIST()返回“≤当前值的行占比”，结果范围也是0.0到1.0，但首行不一定是0.0（例如有重复值时，多个并列第一都会得到相同且非零的累积比例） -
NTILE(4)是把数据**等份切块**（如四分位），每组行数尽量均等，但不保证每组数值范围一致；而PERCENT_RANK()不分组，只给每个点一个连续的位置分数 - 当需要识别“Top 10% 销售员”时，别用
PERCENT_RANK() > 0.9—— 因为它可能一个人都不命中（若最高值多人并列），更稳妥的是用NTILE(10) = 1或RANK() OVER (...)
MySQL 8.0+ 和 PostgreSQL 的兼容性注意点
PERCENT_RANK() 在 MySQL 8.0+、PostgreSQL 8.4+、SQL Server 2005+、Oracle 10g+ 都支持，但旧版本（如 MySQL 5.7）不支持窗口函数，强行使用会报错：ERROR 1064: You have an error in your SQL syntax。
- MySQL 5.7 及更早版本只能用变量模拟，但无法正确处理并列排序，且结果不稳定
- PostgreSQL 中默认按
NULLS LAST处理空值；MySQL 8.0 默认NULLS FIRST（可显式写NULLS LAST调整） - 如果用在视图或子查询中，确保外层不丢失排序上下文——
PERCENT_RANK()的结果依赖于窗口定义，不能靠外层ORDER BY补救
真实销售表里的典型写法
假设表 sales 有字段 salesperson、region、amount，想看各地区销售员的相对表现：
SELECT salesperson, region, amount, ROUND(PERCENT_RANK() OVER (PARTITION BY region ORDER BY amount DESC) * 100, 2) AS pct_rank FROM sales WHERE amount IS NOT NULL;
注意：这里 ROUND(..., 2) 是为了可读性，但不要在 WHERE 中直接用 PERCENT_RANK() > 0.9 过滤——浮点精度可能导致边界行漏掉。真要筛选高分段，优先用 NTILE() 或基于 RANK() + 总数计算阈值。
实际跑出来发现某地区只有 3 人，那他们的 pct_rank 只可能是 0.0、0.5、1.0 —— 小样本下分辨率很低，这点容易被忽略。
