NTILE按排序后行序位置等频分桶，非等宽切分；前余数个桶各多1行，其余桶行数少1，必须配合确定性ORDER BY，不适用于数值区间分层。
NTILE 函数的基本行为和分片逻辑
NTILE 不是随机抽样函数，它按指定顺序将结果集**等宽分组**（不是等频），每组编号从 1 开始递增。如果你没加 ORDER BY，SQL Server 会报错；PostgreSQL 和 Oracle 虽然允许省略，但分组结果不可预测——这恰恰是生成测试数据时最常踩的坑。
真正起作用的是排序依据：相同排序值会被尽量打散到不同桶里（SQL Server 保证“尽可能均匀”，PostgreSQL 则按窗口内行序严格切分）。所以想模拟真实分布，ORDER BY 必须基于有区分度的列，比如 id、时间戳或哈希值。
用 NTILE 构造 4 份均衡测试子集（含 NULL 处理）
假设你有一张 orders 表，想快速拆成训练/验证/测试/预留四份，且要避开 NULL 导致的分组偏斜：
SELECT *,
NTILE(4) OVER (ORDER BY COALESCE(created_at, '1970-01-01'), id) AS fold
FROM orders
WHERE status IS NOT NULL;
这里关键点：
-
COALESCE(created_at, '1970-01-01')防止NULL挤占一个桶导致其余三组变大 - 补上
id作为次级排序，确保相同时间戳的记录不被强行塞进同一桶 -
WHERE提前过滤掉脏数据，避免无效行干扰桶大小计算
NTILE 在不同数据库中的行为差异
MySQL 8.0+ 支持 NTILE，但它的实现更“刚性”：当行数不能被桶数整除时，前面的桶总是多一行（例如 10 行分 4 桶 → 3,3,2,2）；而 SQL Server 会尽量让差值不超过 1（10 行 → 3,3,2,2 或 3,2,3,2，取决于排序稳定性）。Oracle 则默认按 ROWID 排序补位，容易造成物理邻近数据扎堆。
这意味着：跨库迁移测试脚本时，NTILE(5) OVER (ORDER BY id) 在 MySQL 和 SQL Server 中可能给出完全不同的 fold 分布——别依赖“看起来均匀”就认为逻辑一致。
为什么不用 NTILE 做真正的随机抽样
因为 NTILE 是确定性窗口函数，不引入随机性。即使你写 ORDER BY NEWID()（SQL Server）或 ORDER BY RANDOM()（PostgreSQL），也只是把原始顺序打乱后再切桶，本质仍是**伪随机分片**，而非按概率采样。它无法保证每份中类别比例一致（比如正负样本失衡），也不支持放回/不放回语义。
真要控制抽样质量，得配合 TABLESAMPLE（PostgreSQL/SQL Server）、BERNOULLI 或后续用 WHERE + MOD(id, 4) = 0 这类可复现策略。NTILE 的定位很明确：快速切出 N 个大小接近的、带序号的子集，仅此而已。
真正麻烦的是排序键的选择——它决定了你的“测试集”到底在模拟什么分布。选错一列，整个分片就失去业务意义。
