NTILE分组不均是设计行为，按窗口行数优先填满前桶；需注意ORDER BY稳定性、NULL处理、版本兼容性及窗口范围变化影响。
NTILE 函数分组结果不均匀？看窗口定义和行数关系
NTILE 分桶不均不是 bug，是设计行为。它把当前窗口的行按顺序切分成 n 个“尽可能等大的组”，但总行数不能被 n 整除时，前面的组会多 1 行。
比如 7 行数据用 NTILE(3)，结果是 [3,2,2] 而不是 [2,2,3] —— 它永远优先填满靠前的桶。
- 检查你的
ORDER BY是否稳定：如果排序字段有重复值且未加唯一键，NTILE的分配可能每次执行不一致 - 想强制均匀？先用
ROW_NUMBER()+ 算术取整模拟，但要注意 NULL 排序行为 -
NTILE(1)恒为全 1；NTILE(0)直接报错ERROR: invalid argument to NTILE()
在 PostgreSQL 和 SQL Server 中用法一致，但 MySQL 不支持
MySQL 8.0+ 才支持 NTILE，5.7 及更早版本直接报错 FUNCTION xxx.NTILE does not exist。别在迁移脚本里默认假设它存在。
- PostgreSQL / SQL Server / Oracle / BigQuery / Snowflake：语法统一，
NTILE(n) OVER (ORDER BY ...) - SQLite：完全不支持，得用
(ROW_NUMBER() - 1) / CAST(COUNT(*) OVER() AS INTEGER)类似逻辑手写 - 注意空值处理：
ORDER BY col DESC NULLS LAST在 PostgreSQL 有效，SQL Server 用ORDER BY ISNULL(col, 'zzzz')替代
NTILE 配合 WHERE 或 JOIN 后结果突变？其实是窗口范围变了
NTILE 的分组只作用于当前窗口内的行。一旦你在外层加了 WHERE，或 JOIN 后过滤，窗口行数就变了，桶编号自然重排 —— 这不是函数失效，是逻辑前提变了。
- 常见误操作：先
NTILE再WHERE bucket = 1，以为能取“前 1/4 数据”，但实际取的是过滤后结果的前 1/4 - 正确做法：如需固定分组再筛选，先把
NTILE结果存进 CTE 或子查询，再对外层做条件 - 在
GROUP BY后不能直接用NTILE，必须套一层窗口（即NTILE必须出现在最内层 SELECT 或 CTE 中）
性能隐患：NTILE 在大数据量下容易触发磁盘排序
NTILE 必须先完成完整排序才能编号，没有索引支撑的 ORDER BY 字段，在千万级表上可能让查询从秒级拖到分钟级，甚至 OOM。
- 确认
ORDER BY字段有索引，尤其是组合窗口场景下（如PARTITION BY dept_id ORDER BY salary） - 避免在
NTILE的ORDER BY中用函数表达式，如ORDER BY UPPER(name)，会跳过索引 - 如果只要近似分位（比如 Top 10%），考虑用
PERCENT_RANK()+WHERE PERCENT_RANK() > 0.9，部分引擎能走索引优化
真正难的不是写对语法，是想清楚你到底要「按全局排序分桶」还是「按某个维度分别分桶」——漏掉 PARTITION BY 却想要分组内排名，结果就全乱了。
