percent_rank() 最稳，它按排序返回[0,1)内相对排名，首行0末行接近1，相同值同排名，过滤前10%直接 where pr

用 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 <h3>用 <code>COUNT(*)</code> 和子查询算行数阈值要小心重复和边界</h3><p>当数据库不支持窗口函数（如旧版 MySQL），只能靠嵌套查询：先算总行数，再用 <code>LIMIT</code> 或 <code>WHERE</code> 取前 N 行。但这里有两个关键陷阱：</p><p>常见错误现象：</p>

• 用 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 显式控制。