ntile函数将排序后结果集按行数尽可能均分为n组，编号从1开始，余数行优先分配给前组；必须配合order by使用，不按值分布而按行序切分，各桶行数差不超过1。
NTILE函数的基本用法和分组逻辑
NTILE 是窗口函数，作用是把有序结果集**尽可能均等地划分为指定数量的组**，并为每行返回组号（从 1 开始）。它不关心值是否重复，只看排序后的位置——所以分组依据完全是 ORDER BY 子句决定的顺序。
常见错误是以为 NTILE(4) 一定能得到四组“大小完全相等”的数据。实际上：如果总行数不能被 4 整除，NTILE 会把多余的行从第 1 组开始逐个补上。例如 11 行分 4 组，结果是 3、3、3、2；而 13 行分 4 组则是 4、3、3、3。
- 必须配合
OVER (ORDER BY ...)使用，否则报错 - 参数必须是正整数常量或表达式（如
NTILE(5)、NTILE(@n)），不支持列名或子查询 - 分组编号始终从 1 开始，最大不超过指定的 n
处理重复值时的分组不确定性
当 ORDER BY 字段存在大量重复值（比如多个用户 score = 85），SQL 引擎可能以任意顺序排列这些行——导致每次执行 NTILE 分组结果不一致。
这不是 bug，而是标准行为：窗口函数只保证逻辑顺序，不保证物理顺序。要稳定分组，必须让 ORDER BY 具备唯一性：
- 追加主键或唯一字段，如
ORDER BY score DESC, user_id - 避免仅按
name或status排序后直接NTILE - 在测试中发现分组编号“跳变”或前后两次结果不同，大概率是排序键不唯一
与其它分桶函数（如 PERCENT_RANK、NTILE vs WIDTH_BUCKET）的区别
NTILE 是按**行数均分**，而 PERCENT_RANK() 是按**值分布比例**计算排名（0～1 之间），两者目标完全不同。Oracle 用户可能想到 WIDTH_BUCKET，但它按数值区间切分，不是按行数。
典型误用场景：想把销售额 0～100 万分成 5 档（每档 20 万宽），却用了 NTILE(5)——结果变成“销量最高的 1/5 客户为第 1 档”，而非“消费 80～100 万为第 5 档”。这时应该用 CASE WHEN 或数据库特有函数（如 PostgreSQL 的 WIDTH_BUCKET）。
-
NTILE关心“我排第几批”，不关心“我的值落在哪一段” - 需要等宽数值分桶？别硬套
NTILE，先确认业务本质是分位还是分区间 - MySQL 8.0+ 支持
NTILE，但 5.7 及之前不支持，需用变量模拟（易出错且不可并发）
实际分组后如何聚合每组统计信息？
直接在 SELECT 中用 NTILE 只能拿到组号，若要算每组的平均值、最大值等，得嵌套一层：外层按 ntile_group 分组聚合，内层计算 NTILE。
示例：给订单按金额降序四等分，再查每组的平均金额
SELECT ntile_group, AVG(amount) AS avg_amount, COUNT(*) AS cnt FROM ( SELECT amount, NTILE(4) OVER (ORDER BY amount DESC) AS ntile_group FROM orders ) t GROUP BY ntile_group ORDER BY ntile_group;
- 不能在同一个
SELECT层级中同时用NTILE和GROUP BY聚合，会报错 - 如果还需保留原始明细行，就别
GROUP BY，改用AVG(...) OVER (PARTITION BY ntile_group) - 注意 NULL 值：默认排在最前（
NULLS FIRST），可能挤占第 1 组名额；可加WHERE amount IS NOT NULL预过滤
NTILE 时，最容易被忽略的是排序键的确定性，以及对“等份”的机械理解——它分的是行数份额，不是业务意义的均衡。一旦数据分布偏斜（比如 90% 订单金额集中在 100 元以下），NTILE(4) 的第 1 组可能全是 100 元订单，而第 4 组只有几个异常高价单，这种分组对分析未必有用。
