PERCENT_RANK() 为每行计算0–1区间内的相对排名而非直接分组，需配合FLOOR()或NTILE()才能实现等宽分组；必须与ORDER BY窗口子句联用，否则报错。
用 PERCENT_RANK() 实现按百分比分组，不是“切数据”而是“打标签”
直接说结论：PERCENT_RANK() 不是把表拆成几份，而是给每行算一个 0–1 区间内的相对排名（首行为 0，末行为 1），再配合 FLOOR() 或 NTILE() 才能真正分组。很多人误以为它本身就能“分 10 组”，结果发现结果不均匀、边界模糊。
常见错误现象：PERCENT_RANK() 在 GROUP BY 中直接使用报错；或对未排序数据调用，导致排名跳跃；或用它和 COUNT(*) 混搭想“统计每组数量”，却忘了它返回的是浮点值，不能直接 GROUP BY。
-
PERCENT_RANK()必须搭配ORDER BY窗口子句，否则语法错误 - 它基于排序位置计算：第 i 行的值 = (i−1) / (总行数−1)，所以只有 1 行时返回 0，2 行时分别是 0 和 1
- 若需等宽分组（如 Top 10%、Middle 80%），建议先算
PERCENT_RANK()，再用CASE WHEN <code>PERCENT_RANK()这类逻辑分类
NTILE(10) 是更稳妥的“按百分比分组”手段
NTILE() 才是 SQL 标准里专为“把结果集平均分成 N 份”设计的窗口函数。它不依赖具体值分布，只按行数均分——哪怕数据倾斜严重，每组行数最多差 1 行。
使用场景：做用户分层（如 RFM 分群）、报表中划分十分位、A/B 测试随机分桶（配合 ORDER BY RANDOM()）。
-
NTILE(10) OVER (ORDER BY score DESC)表示按score降序，把所有行硬切成 10 组，组号从 1 到 10 - 如果总行数不能被 10 整除（比如 997 行），
NTILE(10)会把前 7 组设为 100 行，后 3 组设为 99 行，保证尽量均衡 - 注意：它不保证每组的
score范围一致，仅保证行数接近——这是和PERCENT_RANK()的本质区别 - PostgreSQL 和 SQL Server 支持，但 MySQL 8.0+ 才支持，旧版 MySQL 需用变量模拟，易出错
聚合时别直接对 PERCENT_RANK() 做 AVG() 或 SUM()
有人写 SELECT AVG(PERCENT_RANK() OVER (ORDER BY x)) FROM t，以为能得到“平均分位”，其实毫无业务意义——因为 PERCENT_RANK() 是窗口函数，不能在非窗口上下文中直接参与聚合；这条语句在多数数据库会报错，或触发隐式窗口（行为不可控）。
正确做法是：先用子查询或 CTE 把分位值算出来，再对外层结果聚合。
SELECT FLOOR(p_rank * 10) AS decile, COUNT(*) AS cnt, AVG(value) AS avg_value FROM ( SELECT value, PERCENT_RANK() OVER (ORDER BY value) AS p_rank FROM sales ) t GROUP BY FLOOR(p_rank * 10);
-
FLOOR(p_rank * 10)把 0–1 映射到 0–9，实现十分位分组（注意：0 表示最低 10%，9 表示最高 10%） - 必须用子查询包裹，否则
GROUP BY和窗口函数混用会出错（尤其在 PostgreSQL 和 Oracle 中） - 这个分组方式实际是“近似等频”，但边界由排序决定，若存在大量重复
value，同一值可能跨两个十分位，造成理解偏差
MySQL 5.7 或更老版本没有窗口函数？用变量模拟 NTILE() 要防排序失效
MySQL 5.7 不支持 NTILE() 和 PERCENT_RANK()，有人用 @row := @row + 1 加子查询算行号，再除以总数——但这极易出错：一旦 ORDER BY 没写进变量赋值语句，或查询被优化器重排，行号就乱了。
典型错误：SELECT @n := @n + 1, ... FROM t, (SELECT @n := 0) r ORDER BY x 看似可行，但 MySQL 不保证 @n 更新顺序与 ORDER BY 同步，尤其在有 LIMIT 或 JOIN 时。
- 安全做法：强制用派生表封装排序 + 变量，例如
(SELECT @n := @n + 1 AS rn, t.* FROM (SELECT * FROM t ORDER BY x) t, (SELECT @n := 0) r) - 再用
FLOOR((rn - 1) / (total_cnt / 10))模拟十分位，其中total_cnt需提前查出或用COUNT(*) OVER()（但 5.7 不支持，只能两遍查询） - 性能影响明显：两次全表扫描 + 排序，大数据量下比原生
NTILE()慢 3–5 倍
真正容易被忽略的是：百分比分组从来不是纯数学操作，它高度依赖排序依据是否代表业务意图。用 created_at 排序分 10 组，和用 amount 排序分 10 组，得到的“Top 10%”完全不是一回事——别让函数替你做业务判断。
