SQL查询：如何快速获取排名前10%的业务销售数据？

先来看一个典型的场景：业务方要求“统计销售业绩排名前10%的销售员”，你很快想到用NTILE(10)把数据分成10组，然后取第1组。结果一查，发现第一组的人数要么多了一个，要么少了一个——尤其是在总记录数不能被10整除的情况下，余数被随机塞进前面几个桶，导致第一组可能占了11%甚至12%。这时候才意识到，NTILE(10) 干的其实是“等份切分”，而不是“按百分比精准筛选”。

用 PERCENT_RANK() 还是 NTILE()？选错函数结果就偏了

直接说结论：PERCENT_RANK() 才是最贴合“前百分之十”语义的函数，而 NTILE(10) 只是把数据等份切分，不保证每组数据量一致，更不保证第1组恰好占总体10%。尤其当总行数不能被10整除时，NTILE(10) 会把余数随机分给前面几个桶，导致第1组可能占11%或9%，极端情况下甚至完全失真。

要实现真正的“前10%”，必须基于排序位置计算相对排名。PERCENT_RANK() 返回的是 (rank - 1) / (总行数 - 1)，范围是0到1，所以过滤 PERCENT_RANK() < 0.1 才准确对应前10%。

• PERCENT_RANK() 按 ORDER BY sales_amount DESC 计算，值越小越靠前
• NTILE(10) 适合“取前10个分组中的第一组”，而不是“前10%”
• 如果业务要求“至少取10条且最多不超过总行数10%”，得额外用 CEILING(COUNT(*) * 0.1) 算出具体行数，再配合 ROW_NUMBER()

ORDER BY 必须明确写，否则 PERCENT_RANK() 结果不可靠

PERCENT_RANK() 是窗口函数，依赖 OVER (ORDER BY ...) 的排序逻辑。漏写 ORDER BY 或排序字段有 NULL 值，排名就会乱掉——比如 NULL 在 DESC 下默认排最前，可能把一堆空销售记录顶进前10%。

• 显式写 ORDER BY sales_amount DESC，避免数据库默认行为差异
• 加 WHERE sales_amount IS NOT NULL 预过滤，防止 NULL 干扰排名基数
• 如果销售金额相同（如多笔0元订单），PERCENT_RANK() 对相同值返回相同排名，但后续行的排名会跳变，这点和 RANK() 类似，需要确认业务是否接受并列

MySQL 8.0+ 和 PostgreSQL 写法一致，但旧版 MySQL 得绕路

MySQL 5.7 及更早版本不支持窗口函数，硬要用“前10%”只能靠变量模拟或子查询嵌套，性能差且易出错。升级到 8.0+ 是最省事的解法。

标准写法（MySQL 8.0+/PostgreSQL）：

SELECT *FROM (  SELECT *,         PERCENT_RANK() OVER (ORDER BY sales_amount DESC) AS pct_rank  FROM sales_records  WHERE sales_amount IS NOT NULL) rankedWHERE pct_rank < 0.1;

• PostgreSQL 同样支持该语法，无需额外适配
• SQL Server 2012+ 也支持 PERCENT_RANK()，但注意其 ORDER BY 不允许 ASC/DESC 缺省，必须显式声明
• 如果只能用 MySQL 5.7，建议先用 SELECT COUNT(*) 算总数，再用 LIMIT 配合 CEILING(@total * 0.1)，但要注意并发下总数可能变化

数据量大时，ORDER BY 字段必须建索引

PERCENT_RANK() 要全表排序，没索引时扫描和排序成本随数据量指数上升。哪怕只有10万行，没索引也可能卡住几秒——而加了 INDEX(sales_amount) 后，执行计划能走 index scan + window aggregation，提速常达10倍以上。

• 复合排序场景（如按区域+金额），建联合索引 INDEX(region, sales_amount)
• 注意索引方向：若常用 ORDER BY sales_amount DESC，MySQL 8.0+ 支持降序索引，显式声明 INDEX(sales_amount DESC) 效果更稳
• 测试时用 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON（MySQL）看是否用了索引、是否触发 filesort

百分比类排名看似简单，但函数选错、NULL 处理漏掉、索引缺失，任何一个点都会让结果偏离预期——尤其是业务拿这数据做激励发放时，错一条都得返工。