PERCENT_RANK() 最稳，它按排序返回[0,1)内相对排名，首行0末行接近1，相同值同排名，过滤前10%直接 WHERE pr < 0.1。
用 PERCENT_RANK() 直接算排名百分比最稳
想取前10%的数据，硬算阈值（比如先查总数、再算 10% 对应的行数）容易出错——尤其数据有重复值或排序字段不唯一时。直接用窗口函数 PERCENT_RANK() 更可靠，它按排序顺序返回 [0, 1) 区间内的相对排名（首行是 0，末行接近但不等于 1）。
实操建议：
-
PERCENT_RANK()基于ORDER BY字段的值分布计算，相同值会得到相同排名，不影响百分比连续性 - 过滤条件写成
WHERE pr ，注意是 ≤ 0.1 而不是 <li>如果排序字段有大量重复值，<code>PERCENT_RANK()仍能保持单调递增，比用ROW_NUMBER()除以总数更合理
SELECT * FROM ( SELECT *, PERCENT_RANK() OVER (ORDER BY score DESC) AS pr FROM students ) t WHERE pr <= 0.1;
用 COUNT(*) 和子查询算行数阈值要小心重复和边界
当数据库不支持窗口函数（如旧版 MySQL），只能靠嵌套查询：先算总行数，再用 LIMIT 或 WHERE 取前 N 行。但这里有两个关键陷阱：
常见错误现象：
- 用
FLOOR(COUNT(*) * 0.1)当阈值，结果为 0（总数 - 用
ROW_NUMBER()排序后取rn ，但相同 <code>score的多条记录可能被截断，破坏业务语义（比如并列第 5 名有 3 人，只取前 2 个） - 子查询里没加
ORDER BY，ROW_NUMBER()排序结果不可控
实操建议：
- 用
CEIL(COUNT(*) * 0.1)替代FLOOR，确保至少取 1 行 - 把排序逻辑写死在子查询的
ORDER BY中，例如ORDER BY score DESC, id ASC消除不确定性 - 若需“并列不跳过”，改用
RANK()并配合外层去重或业务逻辑兜底
NTILE(10) 分十分位适合分组分析，不适合精确取前10%
NTILE(10) 把结果集平均分成 10 组（编号 1–10），看似能取 ntile = 1 就是前 10%，但实际它按行数均分，不是按值分布。比如 99 行数据，NTILE(10) 会生成大小为 10、10、10… 的 9 组 + 1 个 9 行组，第一组未必对应最高 10% 的值。
使用场景：
- 做分桶统计（如“各十分位的平均薪资”）可以，
GROUP BY ntile - 不能替代
PERCENT_RANK()做阈值过滤，尤其当数据量不能被 10 整除或存在长尾分布时 - MySQL 8.0+、PostgreSQL、SQL Server 支持，但 SQLite 不支持
不同数据库对 PERCENT_RANK() 的兼容性差异
主流数据库基本都支持 PERCENT_RANK()，但细节行为略有不同：
- PostgreSQL 和 SQL Server：严格按标准实现，空值默认排在最后（可通过
NULLS FIRST/LAST控制） - MySQL 8.0+：支持，但
ORDER BY子句中不能混用升序降序（如ORDER BY a ASC, b DESC会报错） - SQLite：不支持窗口函数，必须降级用子查询 +
(SELECT COUNT...)关联 - Oracle：支持，且允许在
ORDER BY中指定NULLS LAST，推荐显式声明避免歧义
真正容易被忽略的是空值处理——如果排序字段含 NULL，不同数据库默认行为不一致，务必在 ORDER BY 里加 NULLS LAST 或 NULLS FIRST 显式控制。
