NTILE分组结果不稳定是因为排序字段重复导致行序不可复现，必须用唯一键（如user_id）兜底；它按有序行切片而非随机分流，余数行优先分配给前桶，不保证绝对均匀。
NTILE函数分组结果不稳定？先确认排序字段是否唯一
NTILE(2) 不能保证每次划分出严格相等的A/B两组，根本原因是它按ORDER BY子句排序后“切片”，如果排序字段存在重复值，SQL Server 或 PostgreSQL 会任意打乱相同值的行顺序，导致分组结果不可复现。A/B测试最怕这个——今天用户进A组，明天跑B组。
实操建议：
- 必须用带唯一性的字段排序，比如
user_id、created_at + id组合，或加ROW_NUMBER() OVER (ORDER BY user_id)作为稳定序号 - 避免用
gender、country这类低基数字段直接排序 - 测试前先查
COUNT(*)和COUNT(DISTINCT sort_key)，确保排序键无大量重复
NTILE(2) ≠ 均匀随机分流，别把它当rand()用
NTILE(2) 是确定性分桶：把有序数据平均切成两块，首半段是1，后半段是2。它不打乱顺序，也不考虑用户属性分布。如果你的用户表按注册时间插入，且新用户集中在末尾，NTILE(2) 会把老用户全分进A、新用户全进B——造成人群偏差。
正确做法取决于目标：
- 要统计意义下的均衡分流：先用
ORDER BY RANDOM()（PostgreSQL）或ORDER BY NEWID()（SQL Server）打乱，再套NTILE(2) - 要长期稳定的用户归属：用
NTILE(2) OVER (ORDER BY user_id % 1000)这类哈希排序，比纯随机更易复现 - 要按业务维度平衡（如地域、设备）：得先
PARTITION BY region, device_type，再对每个分区单独NTILE(2)
不同数据库对NTILE的NULL和空集处理差异大
遇到 NTILE(2) OVER (ORDER BY score) 返回全是 NULL？不是语法错，是数据问题。SQL Server 把 NULL 排在最前面，而 PostgreSQL 默认排最后，且部分版本会跳过 NULL 行参与分桶——同一语句在两地结果可能完全不一致。
安全写法：
- 显式过滤：
WHERE score IS NOT NULL再分桶 - 统一补值：
ORDER BY COALESCE(score, 0)，但注意补0可能影响分布 - 检查空集：
COUNT(*) FILTER (WHERE score IS NULL)（PostgreSQL）或SUM(CASE WHEN score IS NULL THEN 1 ELSE 0 END)（SQL Server）
NTILE做A/B分流时，千万别忽略样本量临界点
当总行数不能被分桶数整除，NTILE会把余数逐个分给前面的桶。比如 1001 行用 NTILE(2)，结果是 A 组 501 人、B 组 500 人；但用 NTILE(3) 就变成 334/334/333 —— 看似公平，实际第三组永远少1人。A/B测试中，哪怕1%的偏差，在小流量场景下（比如每天只1000用户）就足以让p值失效。
关键提醒：
- 上线前必须算：
SELECT COUNT(*) % 2 AS remainder FROM users，确认余数是否可接受 - 若需绝对均等，改用
ROW_NUMBER() % 2（取模），但注意它依赖排序稳定性 - 真正严谨的实验平台不会只靠NTILE，而是结合用户ID哈希+预分配桶表，NTILE最多用于临时探查
NTILE本身不生成随机性，它只是切刀；真正的A/B控制力，藏在你选什么排序、怎么处理边界、以及是否验证了每组的实际分布。
