percent_rank()通过公式(rank-1)/(partition_row_count-1)计算相对位置值，取“前10%”即筛选结果≤0.1的行，需配合order by使用。
PERCENT_RANK() 是怎么算出“前10%”的
PERCENT_RANK() 不是直接返回“第几百分位”，而是按公式 (rank - 1) / (partition_row_count - 1) 算一个介于 0.0 和 1.0 之间的相对位置值。它依赖排序后的 RANK()（并列不跳号），且必须有 ORDER BY，否则报错 Window function PERCENT_RANK requires ORDER BY。
想取“前10%”，本质是筛选 PERCENT_RANK() 的行——注意不是 <code>，因为首行恒为 <code>0.0，必须包含端点。
- 分组只有一行时，
PERCENT_RANK()返回0.0（不是 NULL），该行会被捕获 - 分组只有两行时，排名分别是
0.0和1.0，此时只能取到第一行 - 分组有 10 行以上时，
0.1大致对应前 2 名左右（因分布非线性），比硬写ROW_NUMBER() 更适应数据量变化
正确写法：PARTITION BY + ORDER BY 缺一不可
漏掉 PARTITION BY 就变成全表统一排序；漏掉 ORDER BY 则直接报错。典型错误写法：PERCENT_RANK() OVER(PARTITION BY customer_segment) —— 缺少排序，数据库拒绝执行。
正确结构示例（按客户生命周期价值 LTV 降序取各区域前10%）：
SELECT region, customer_id, ltv,
PERCENT_RANK() OVER (PARTITION BY region ORDER BY ltv DESC) AS pct_rk
FROM customers
WHERE pct_rk
-
PARTITION BY region确保每个区域独立计算，互不影响 -
ORDER BY ltv DESC决定“高价值”的方向：值越大越靠前，pct_rk越小 - 不能用常量排序，如
ORDER BY 1或ORDER BY 'x'，会报语法错误
MySQL 8.0 以下版本无法使用，得换思路
MySQL 5.7 及更早版本执行 PERCENT_RANK() 会报错：FUNCTION db.PERCENT_RANK does not exist。MariaDB 10.2+、PostgreSQL 8.4+、SQL Server 2005+、Oracle 10gR2+ 才原生支持。
替代方案只能靠变量模拟，但有硬伤：
- 无法正确处理并列值（所有相同
ltv客户会得到不同pct_rk） - 子查询嵌套后，
ORDER BY在派生表中可能被忽略，导致排序失效 - 在
WHERE或HAVING中无法直接引用窗口别名，必须套一层子查询
所以如果环境受限，更稳妥的做法是改用 NTILE(10) 分桶后取 ntile = 1，虽然边界略粗糙，但兼容性好、逻辑清晰。
容易被忽略的 NULL 和精度问题
PERCENT_RANK() 对 NULL 值默认按排序规则排在最前或最后（取决于 ORDER BY ... NULLS FIRST/LAST，但多数数据库不支持该子句）。若 ltv 字段含 NULL，它们会参与分组计数和排名，拉低有效客户的占比精度。
另一个常见疏忽是没做类型转换：整数除法会导致结果截断为 0。虽然 PERCENT_RANK() 自身返回 DOUBLE，但如果你后续手动算百分比（比如乘 100 显示），记得用 100.0 而非 100，否则 PostgreSQL/MySQL 可能返回整型 0。
真正难处理的是「分组行数极少」时的语义漂移：3 行分组里 pct_rk 值只能是 0.0、0.5、1.0，此时 实际只取到 1 行，而非严格意义的 10%。业务上是否接受这种离散误差，得提前对齐。
