percent_rank() 最贴近“前百分之十”语义，因其基于排序位置计算相对排名，返回值范围为0到1，可精准筛选前10%；ntile(10) 仅等份数切分，无法保证每组占比精确为10%，尤其在总行数不能被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() 才准确对应前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+ 是最省事的解法。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
标准写法（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
) ranked
WHERE pct_rank
- 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 处理漏掉、索引缺失，任何一个点都会让结果偏离预期——尤其是业务拿这数据做激励发放时，错一条都得返工。
