PERCENT_RANK() 更适合“前N%”需求，因其直接返回0–1间相对排名，语义清晰且结果确定；而NTILE()分组大小不均、边界模糊，无法精确对应百分比。
为什么
比
更适合“前N%”需求
因为
直接返回相对排名（0 到 1 之间），而
是强行把数据切成 N 组，组大小不均、边界模糊——比如你想要前 15%，
看似能凑合，但实际分组数和百分比不是一一对应，尤其当总行数不能被 100 整除时，第 1 组可能占 1.2%，也可能占 0.8%。
实操建议：
基于排序位置计算：(rank - 1) / (总行数 - 1)，首行必为 0，末行必为 1
要取前 20%，直接写
，语义清晰、结果确定
注意：必须配合
，且窗口定义里不能带
（除非你真要每组独立算百分比）
分组内前N%怎么写？关键在
和
的组合顺序
常见错误是只加
却忘了在每个组内指定排序依据，导致
默认按物理顺序排，结果随机。
正确写法示例（取每个部门薪资前 10% 的员工）：
要点：
决定“分组范围”，
决定“组内排序方向”，缺一不可
如果用
，那就是“最低的 10%”，不是“最高的 10%”，容易看反
空值（
）默认排在最前（
）或最后（
），若字段可能为空，建议显式加
或
和
的区别在哪？什么时候该换
两者都返回 0–1 区间值，但逻辑不同：
是“比你小的人占比”，
是“小于等于你的人占比”。当有重复值时，结果差异明显。
比如某组 5 行数据，值为 [100, 90, 90, 80, 70]，按降序排：
对两个 90 分别返回 0.25（第 2 名，(2−1)/(5−1)=0.25）
对两个 90 都返回 0.6（前 3 行 ≤ 90，3/5=0.6）
所以：要严格按“位置比例”卡前 N%，用
；要包含并列项、确保不漏掉相同分数的记录，用
。
性能和兼容性要注意什么？特别是 MySQL 和旧版 PostgreSQL
是 SQL:2003 标准函数，现代数据库基本都支持，但 MySQL 直到 8.0 才支持窗口函数，PostgreSQL 8.4+ 支持，SQLite 3.25+ 支持。
性能方面：
全表扫描不可避免，但加好索引能加速排序：比如
复合索引对
效果显著
大数据量下，
计算本身开销不大，瓶颈通常在排序阶段，别指望它比
快
某些场景（如只取 Top 1% 且数据高度倾斜），先用子查询过滤出大致范围再算百分比，可能比全量窗口更高效
真正容易被忽略的是：百分比阈值写死在 WHERE 里时，如果业务要求动态传参（比如前端选 5%/10%/25%），得确认 ORM 或驱动是否支持参数化窗口函数表达式——很多不支持，得拼 SQL 字符串，这里容易埋 SQL 注入坑。
PERCENT_RANK()NTILE()PERCENT_RANK()NTILE()NTILE(100)PERCENT_RANK()PERCENT_RANK() OVER (ORDER BY score DESC) < 0.2ORDER BYPARTITION BYPARTITION BYORDER BYPARTITION BY dept_idPERCENT_RANK()SELECT emp_id, dept_id, salary
FROM (
SELECT emp_id, dept_id, salary,
PERCENT_RANK() OVER (
PARTITION BY dept_id
ORDER BY salary DESC
) AS pct_rank
FROM employees
) t
WHERE pct_rank < 0.1;PARTITION BY dept_idORDER BY salary DESCASCNULLASCDESCNULLS LASTNULLS FIRSTPERCENT_RANK()CUME_DIST()PERCENT_RANK()CUME_DIST()PERCENT_RANK()CUME_DIST()PERCENT_RANK()CUME_DIST()PERCENT_RANK()(dept_id, salary DESC)PARTITION BY dept_id ORDER BY salary DESCPERCENT_RANK()LIMIT