NTILE分桶不均匀是设计行为，非bug；它按排序后行序将数据尽可能均分为N组，余数行优先分配给前几组，如10行分3桶得[4,3,3]。
NTILE 为什么分桶经常不均匀
因为 NTILE 的设计目标不是“每桶数量相等”，而是“把排序后的结果尽可能平均地分成 N 组”，当总行数不能被桶数整除时，它会把多余的行逐个分配给前面的桶。比如 10 行分 3 桶，结果是 [4, 3, 3]；11 行分 3 桶就是 [4, 4, 3]。这不是 bug，是规范行为。
常见错误现象：NTILE(4) OVER (ORDER BY score) 返回的桶号中，1 号桶有 27 行、2 号桶只有 25 行，误以为写错了或数据异常——其实完全正常。
- 必须先
ORDER BY，否则分桶顺序不可控（SQL 标准要求） - 相同排序值的行可能被分到不同桶，因为
NTILE只看位置，不看值是否重复 - 窗口内若含
NULL，它们会被排在最前或最后（取决于ORDER BY ... NULLS FIRST/LAST），影响桶边界
想强制均匀？得绕开 NTILE 自己算
真正需要“每桶最多差 1 行”的场景（如抽样、分页展示、负载均衡分发），NTILE 不够用，得用整除+余数逻辑手动分桶。
核心思路：先用 ROW_NUMBER() 编号，再用 (rn - 1) / bucket_count 整除得到桶号（从 0 开始），最后 +1。
SELECT *,
(ROW_NUMBER() OVER (ORDER BY score DESC) - 1) / 4 + 1 AS manual_quartile
FROM scores;- 这里
/ 4是整数除法（PostgreSQL/SQL Server/Oracle 支持；MySQL 8.0+ 需用FLOOR((rn-1)/4)） - 相比
NTILE(4)，这个结果严格保证：桶大小要么是⌊n/4⌋，要么是⌈n/4⌉，且大桶全在前面 - 如果要让大桶均匀散开（比如避免第一桶过大），就得加随机扰动：
ORDER BY score, RANDOM()或NEWID()
NTILE 和其他分桶函数的适用边界
NTILE 真正适合的场景，是“相对位置分层”而非“绝对数量均分”。比如：按销售额把客户分为 top 10%、middle 80%、bottom 10%，这时用 NTILE(10) 再过滤 bucket IN (1,10) 更自然。
-
PERCENT_RANK()和CUME_DIST()更适合百分位划分，不受桶数整除限制 -
WIDTH_BUCKET()（Oracle/PostgreSQL）按数值区间切桶，和NTILE完全不同维度——它不管行数，只管值域分布 - 如果字段有大量重复值，
NTILE和RANK()行为差异明显：RANK()对相同值给同名次并跳号，NTILE则仍按物理位置分
容易被忽略的兼容性细节
不同数据库对 NTILE 的 NULL 处理和整数除法规则不一致，跨平台迁移时最容易出问题。
- SQL Server：
NTILE中NULL默认排最前，且ORDER BY col ASC会把NULL当最小值 - PostgreSQL：需显式写
ORDER BY col NULLS LAST才能控制NULL位置，否则行为依赖配置 - MySQL 5.7 不支持窗口函数，MySQL 8.0+ 支持
NTILE，但整数除法/返回 decimal，必须用FLOOR()或CAST(... AS SIGNED) - BigQuery 中
NTILE不接受表达式作为参数，只能是常量数字，比如不能写NTILE(@n)
实际写的时候，别只测“刚好整除”的 case，一定要用 101 行分 10 桶这种典型余数场景跑一遍结果——多出来的那 1 行落在哪，决定了下游逻辑会不会偏移。
