NTILE函数不能保证每桶行数绝对相等，但会尽量使各桶行数相差不超过1；其按排序后行序位置均分，与数值分布无关，必须配合ORDER BY使用，且不支持ROWS BETWEEN等帧子句。
NTILE 函数到底能不能“均匀”分桶？
不能完全保证每桶行数绝对相等，但会尽量让各桶行数相差不超过 1。NTILE(n) 的核心逻辑是：先计算总行数除以 n 的商（基础桶大小）和余数 r，然后前 r 个桶各多分 1 行。所以当总行数不能被 n 整除时，前几个桶会略大。
常见误判是以为 NTILE 会按值范围切分（像 PERCENT_RANK 或直方图），其实它只按排序后的**行序位置**均分，和数值分布无关。
- 必须配合
ORDER BY使用，否则语法报错：Window function ntile requires an ORDER BY clause - 不支持
ROWS BETWEEN等帧子句，只能用于完整窗口（OVER (ORDER BY ...)） - 若排序字段存在大量重复值，NTILE 仍会严格按物理顺序（如输入顺序或主键顺序）继续编号，不会合并相同值到同一桶
如何避免因 NULL 或重复排序键导致分桶偏斜？
NULL 在 ORDER BY 中默认排在最前（NULLS FIRST），如果字段含大量 NULL，它们会被集中塞进前几个桶，破坏均匀性。重复值本身不导致问题，但若你期望“相同业务 ID 必须同桶”，NTILE 无法保证——它只看行序，不聚类。
- 显式处理 NULL：
ORDER BY COALESCE(sort_col, 'ZZZZ') ASC把 NULL 推到最后，或用CASE WHEN sort_col IS NULL THEN 1 ELSE 0 END, sort_col控制优先级 - 添加确定性次级排序：例如
ORDER BY status, id比单用status更稳定，避免不同执行计划下相同值的行序漂移 - 若需“相同值必须同桶”，NTILE 不适用，应改用
GROUP BY + ROW_NUMBER() OVER (PARTITION BY ...)配合外部逻辑
NTILE 在大数据量下的性能陷阱
NTILE 是窗口函数，必须对全结果集排序并扫描两次（一次定总数，一次算桶号），数据量超千万后容易触发磁盘临时表或 OOM。PostgreSQL 和 SQL Server 对大窗口优化较好；MySQL 8.0+ 支持但无并行；Spark SQL 的 ntile 会引发全 shuffle。
- 提前过滤：在
OVER子句外用WHERE尽量缩小输入行数，不要在窗口内靠FILTER（多数方言不支持） - 慎用高基数排序字段：比如对
created_at（毫秒精度）排序，会导致几乎无重复，但排序开销陡增；可考虑先DATE(created_at)降精度再分桶 - 替代方案参考：若只要近似均匀抽样，
WHERE ABS(HASH(id)) % n = 0（MySQL/BigQuery）或TABLESAMPLE SYSTEM (10)更快，但非严格分桶
实际写法：带偏移校准的四分桶示例
假设要将用户表按注册时间分成 4 个运营桶，且希望新用户（NULL 注册时间）归入最后一桶：
SELECT
user_id,
registered_at,
NTILE(4) OVER (
ORDER BY
CASE WHEN registered_at IS NULL THEN 1 ELSE 0 END,
registered_at DESC,
user_id
) AS bucket_id
FROM users;
这里用 CASE 把 NULL 归为高优先级（值为 1），再按 registered_at DESC 让新用户靠前，最后用 user_id 保序稳定。注意 DESC 是关键——否则最新注册用户会挤在第一桶，而非你想要的“第 4 桶是最新一批”。
真正难的不是写对语法，而是想清楚“均匀”对你意味着什么：是行数均匀？时间跨度均匀？还是业务语义上的均衡？NTILE 只负责前者，其余得靠你预处理排序逻辑。
