NTILE分组不均匀是设计行为，非bug；它将有序数据尽可能均分为n组，余数从第1组起逐一分配，如17行分5组得4,4,3,3,3。
NTILE函数分组结果为什么总是不均匀？
NTILE(n) 并不保证每组行数完全相等，它只是把有序结果集尽可能平均分成 n 组，余数会从第1组开始逐一分配。比如 17 行数据用 NTILE(5)，会得到 4,4,3,3,3 的分布——这不是 bug，是设计行为。
如果你需要严格等量（如“前20%”必须精确），不能依赖 NTILE 直接切分，得结合 COUNT(*) OVER() 算比例边界：
SELECT *,
CASE
WHEN rn <h3>NTILE和ROW_NUMBER、RANK混用时排序逻辑要统一</h3><p>多个窗口函数共用同一 <code>ORDER BY</code> 子句时，SQL 引擎可能因优化策略导致隐式排序不一致，尤其在有重复值的字段上（如多人同分）。最稳妥做法是显式声明相同排序表达式：</p>
- 错误写法：
NTILE(4) OVER (ORDER BY score DESC)和RANK() OVER (ORDER BY score DESC, id ASC)—— 排序依据不一致，分组和排名可能错位 - 正确写法：所有窗口函数都用
ORDER BY score DESC, id ASC，确保顺序确定
否则你会看到某条记录被分到第3组，但它的 RANK() 却是第1名——这不是数据问题，是窗口定义冲突。
NTILE在MySQL 8.0+和PostgreSQL中行为一致，但旧版MySQL不支持
MySQL 5.7 及更早版本没有 NTILE，强行使用会报错 ERROR 1305 (42000): FUNCTION xxx.NTILE does not exist。升级到 8.0+ 是唯一解，别试图用变量模拟——性能差且并发不安全。
PostgreSQL 从 8.4 起就支持，语法完全兼容；SQL Server 同样支持，但注意其默认排序为 ASC，而业务常需降序，漏写 DESC 会导致高分进末组。
跨数据库迁移时，检查执行计划里的 WindowAgg 节点是否出现，能快速确认 NTILE 是否被真正下推执行而非退化为嵌套循环。
用NTILE做资源分配时，权重必须落在分组后聚合层
直接对 NTILE 结果做 SUM(amount) 是常见误区。比如想给 Top 25% 客户多分 30% 预算，不能写：
-- 错误：NTILE在WHERE里不可用，且逻辑颠倒 SELECT SUM(amount) * 1.3 FROM t WHERE NTILE(4) OVER(...) = 1;
正确路径是两层处理：
- 第一层：用
NTILE(4) OVER (ORDER BY value DESC)标出每条记录所属等级 - 第二层：按等级
GROUP BY，再用CASE WHEN给不同等级乘对应系数
否则你分配的不是“资源”，而是“幻觉中的资源”——因为没聚合就加权，单条记录权重失去业务意义。
NTILE 的真正难点不在语法，而在它强制你把“连续指标”切成“离散桶”，而现实业务的阈值往往不是整除关系。别迷信分组数字，盯住每个桶的实际人数和数值区间，才是资源分配不出偏差的关键。
