ROW_NUMBER() OVER (ORDER BY NEWID()) 是SQL Server中实现近似均匀AB分组的最简原生方案，通过取模和CASE语句映射为分组标识，但不适用于需稳定哈希或高统计要求的场景。
ROW_NUMBER() 配合 ORDER BY NEWID() 是最简可行方案
直接用 ROW_NUMBER() OVER (ORDER BY NEWID()) 生成随机序号，再对分组数取模即可实现近似均匀的AB分组。SQL Server 中 NEWID() 每行返回唯一随机 GUID，排序效果等价于物理重排，是目前最轻量、无需临时表、不依赖扩展函数的原生做法。
常见错误是误用 ORDER BY RAND()（MySQL 写法）或 ORDER BY RANDOM()（PostgreSQL），在 SQL Server 中会报错 Invalid column name 'RAND'；也有人试图用 CHECKSUM(NEWID()) 再排序，纯属冗余——NEWID() 本身已足够随机。
- 必须写在窗口函数内：
ROW_NUMBER() OVER (ORDER BY NEWID())，不能先SELECT NEWID()再排序（那只会生成一列固定值） - 若需复现结果，无法用
NEWID()；应改用带种子的CHECKSUM(NEWID(), @seed)+ABS()模拟，但会牺牲部分均匀性 - 大数据量下
ORDER BY NEWID()有性能代价（全表排序），100 万行以内通常可接受
分组逻辑：用 % 运算符做模运算，注意起始值偏移
得到随机序号后，% 2 得到 0 或 1，但多数业务要求分组名是 'A'/'B' 而非 0/1，且常希望 A 组略多（当总行数为奇数时）。直接 CASE WHEN rn % 2 = 1 THEN 'A' ELSE 'B' END 会让奇数序号进 A，但 ROW_NUMBER() 从 1 开始，所以第 1 行是 A，第 2 行是 B……实际是均衡的。
更稳妥的做法是统一从 0 开始编号再模：用 (ROW_NUMBER() OVER (ORDER BY NEWID()) - 1) % 2，这样模结果严格轮换，语义更清晰。
- 分 3 组（A/B/C）就写
% 3，对应CASE WHEN mod = 0 THEN 'A' ... - 避免用
ROUND(RAND() * N, 0)类方式——它不保证全局均衡，单次查询内可能全分到 A - 不要在 WHERE 中提前过滤再分组，否则样本偏差：必须先完成随机序号分配，再按分组字段筛选
确保每次查询结果稳定：加 WITH (NOLOCK) 不够，得固化随机种子
AB 测试要求同一用户始终落在同一组，否则数据不可比。仅靠 NEWID() 每次执行都变，无法满足。此时必须引入稳定哈希：用用户标识字段（如 user_id）参与计算，例如 ABS(CHECKSUM(user_id)) % 2。
但注意 CHECKSUM() 有碰撞风险，且负数取模行为因 SQL Server 版本而异；更可靠的是 ABS(CONVERT(BIGINT, HASHBYTES('MD5', CAST(user_id AS VARCHAR))) % 2)，不过开销略高。
- 如果 user_id 是字符串，务必先
CAST成一致类型，否则CHECKSUM('123')和CHECKSUM(123)结果不同 - 测试阶段可用
WHERE user_id IN (...)小批量验证分组一致性，确认同一 ID 每次都进同一组 - 上线前检查 NULL 值：若
user_id可为空，CHECKSUM(NULL)恒为 NULL，导致整组丢失，需先ISNULL(user_id, 'unknown'+CAST(GETDATE() AS VARCHAR))
和真实随机数生成器对比：别把 ROW_NUMBER 当概率引擎
ROW_NUMBER() + NEWID() 本质是「伪随机重排序」，不是统计学意义的独立同分布抽样。它能保证两组数量差 ≤1（当用 (rn-1)%N），但无法控制「连续 10 行不出现 A 组」这类序列特征。
如果 AB 测试需要严格满足 Wald 检验前提，或涉及序贯分析（sequential testing），必须导出数据后用 Python/R 重分组；SQL 层只适合快速切片、灰度发布、邮件分流等对随机质量要求不苛刻的场景。
真正容易被忽略的是时间维度：用 GETDATE() 或 SYSDATETIME() 做种子看似可复现，实则每毫秒都不同，反而破坏稳定性。稳定分组永远要锚定业务主键，而不是运行时上下文。
