ntile(4)将结果集按order by排序后尽可能均匀分为4组，编号1–4；总行数不能被4整除时，小编号组多至多1行；必须配合over()和order by使用，null需显式处理，不保证相同值同组。
NTILE(4) 的基本用法和分组逻辑
NTILE(4) 会按指定排序将结果集**尽可能均匀**地划分为 4 组，每组分配一个从 1 到 4 的整数标签。它不保证每组行数完全相等——当总行数不能被 4 整除时，较小编号的组会多出至多 1 行（例如 17 行 → 分组大小为 5,5,4,3）。
关键点在于：NTILE 是窗口函数，必须配合 OVER() 使用，且 ORDER BY 子句不可省略，否则报错 Window function NTILE requires an ORDER BY clause。
- 排序字段决定梯队划分依据（如按
score DESC划高分梯队，按created_at ASC划新用户梯队） - 相同排序值的行可能被分到不同组（NTILE 不做稳定分组，不保证相同值同组）
- 若需相同分数进同一梯队，应先用
DENSE_RANK()或聚合预处理，再人工归并
常见错误：NULL 值导致分组错乱或报错
NTILE 本身不拒绝 NULL，但 ORDER BY 中若含 NULL，默认排序行为因数据库而异（PostgreSQL/SQL Server 将 NULL 排在最前，MySQL 8.0+ 默认排最后）。这会导致 NULL 用户被集中分进第 1 组或第 4 组，严重偏离“等分”预期。
- 显式控制 NULL 位置：用
ORDER BY score DESC NULLS LAST（PostgreSQL）或ORDER BY CASE WHEN score IS NULL THEN 1 ELSE 0 END, score DESC（通用写法） - 更稳妥的做法是提前过滤或归类 NULL：比如
WHERE score IS NOT NULL，再对有效用户等分 - 若业务上 NULL 代表“未参与”，通常不应参与梯队划分
实际 SQL 示例与参数陷阱
假设表 users 有字段 id、name、score，目标是按分数从高到低分 4 梯队：
SELECT id, name, score,
NTILE(4) OVER (ORDER BY score DESC NULLS LAST) AS tier
FROM users
WHERE score IS NOT NULL;
注意几个易错细节：
-
NTILE(4)的参数必须是常量表达式，不能是变量或列名（如NTILE(num_tiers)在多数引擎中非法） - 若在子查询或 CTE 中使用，确保
OVER()的排序逻辑与最终需求一致——加了LIMIT或WHERE后再套 NTILE 会导致分组基于子集而非全量 - MySQL 8.0+ 支持，但 MySQL 5.7 及更早版本不支持窗口函数，会报错
FUNCTION xxx.NTILE does not exist
验证分组是否“等分”：别只看 COUNT(*)
直接 GROUP BY tier 看各组行数，只能确认数量分布，无法判断分组是否符合业务意图。例如：最高分 100 的 20 人全被分进 tier=1，但第 2 高分只有 80，中间断层极大——这时“等分人数”不等于“梯队能力均衡”。
- 检查边界值：用
MIN(score)和MAX(score)查每组分数范围，确认是否有不合理断层 - 警惕数据倾斜：若某组人数明显偏少（如 1000 行数据，tier=4 只有 1 行），大概率是 NULL 或异常值干扰了排序
- 真正需要“按分数段等分”时，
NTILE不是最佳选择——应改用PERCENT_RANK()或手动计算分位点后CASE WHEN
NTILE 的本质是“按序切块”，不是“按值聚类”。理解这点，才能避免把它当成自动分箱工具来用。
