NTILE(n)是将有序结果均分n组并编号，不处理重复值；RANK()则按值严格排名并跳过并列名次；二者排序逻辑不一致时结果必然错位，需统一ORDER BY表达式；NTILE无法保证精确百分比分割。
NTILE 是分桶，RANK 是打名次
NTILE(n) 不是“排名”，而是把有序结果集切分成 n 个大小尽可能均等的组，每组给一个编号（从 1 开始）。它不管值是否重复、也不管名次是否连续，只管“平均分堆”。RANK() 则严格按值排序并处理并列：相同值获得相同名次，后续名次跳过（比如两个第 1 名，下一个是第 3 名）。
相同数据下分组结果可能完全错位
当存在大量重复值时，RANK() 和 NTILE(4) 的输出几乎必然不一致：
-
RANK()会把所有同分记录挤在同一个名次上，导致后续名次大幅后移 -
NTILE(4)仍会强制把行数均分进 4 组，哪怕前 100 行全是同一分数，它也会硬拆成 25+25+25+25 —— 这些组里混着完全相同的值 - 典型错误：用
NTILE(4) = 1当作“前 25% 高分用户”，但实际可能是“分数中等、数量凑够的前 25% 行”
排序表达式不统一就容易出逻辑矛盾
如果同时用 NTILE(4) OVER (ORDER BY score DESC) 和 RANK() OVER (ORDER BY score DESC, id ASC)，两者的底层排序顺序其实不同：
-
NTILE只看score，相同分的行谁先谁后由优化器决定（不稳定） -
RANK显式加了id ASC，相同分时有确定顺序 - 结果就是：某条记录
RANK() = 1，但它被分进了NTILE = 3组——不是数据错了，是窗口定义冲突 - 正确做法：所有窗口函数共用完全一致的
ORDER BY表达式，例如都写成ORDER BY score DESC, id ASC
需要精确百分比切分时 NTILE 不可靠
NTILE 分组天然不均等。17 行用 NTILE(5) 得到的是 4,4,3,3,3；这不是 bug，是设计行为。如果你要“严格前 20%”或“Top 100”，必须换思路：
- 用
COUNT(*) OVER()算总数，再结合ROW_NUMBER()算位置比例 - 例如：
WHERE rn -
NTILE适合“大致分层运营”，不适合“精准阈值控制”
真正难处理的，是业务方一边说“按消费分五级”，一边又要求“VIP 必须是消费最高的前 100 人”——这时候不能只靠 NTILE，得把分组逻辑和人数约束拆开算。
