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