SQL Server中随机抽样必须用ORDER BY NEWID()，因其逐行生成唯一GUID实现真随机；RAND()在单语句中只计算一次，导致排序固定、条件恒真/假，无法用于随机抽样。
直接用 ORDER BY NEWID() 就能随机抽，但大表会卡死——这不是语法问题，是执行计划层面的全表扫描+内存排序硬伤。
为什么 RAND() 在 SQL Server 里根本不能用作随机排序
因为 RAND() 是确定性函数，在单条语句生命周期内只计算一次。写 ORDER BY RAND() 实际上等价于按一个固定值排序，结果永远不变。哪怕你加了 WHERE RAND() > 0.5，这个条件在编译阶段就被优化成恒真或恒假，整张表该扫还得扫，还抽不到想要的样本。
-
RAND()只适合给变量赋初值，比如DECLARE @r FLOAT = RAND() - 想靠它控制抽样比例？基本等于写了个逻辑 bug
- MySQL 和 PostgreSQL 的
RAND()/random()行为完全不同，不能跨库类比
ORDER BY NEWID() 真正起作用的关键点
NEWID() 每次调用都生成新 GUID，SQL Server 强制它在 ORDER BY 中逐行求值——这才是“每行一个随机值”的底层保障。
- 必须写成
ORDER BY NEWID()，不要先SELECT *, NEWID() AS r再ORDER BY r（多占一列、无实质提速） - 不能出现在视图、内联表值函数、计算列中，SQL Server 明确禁止非确定性函数用于这些对象
- 事务中多次执行，每次结果都不同，且不受隔离级别影响，也无法回滚到“上一次随机状态”
- 小表（TOP N 并明确字段，避免宽表拖慢
大表（50 万+ 行）怎么避免性能崩掉
全表扫描 + 排序在大数据量下会迅速吃光内存，Sort 运算符成为瓶颈，甚至触发磁盘溢出。别硬扛。
- 优先走应用层：查出
MIN(id)和MAX(id)，程序生成几个随机 ID，再WHERE id IN (...)查询——前提是主键连续或稀疏度可控 - 纯 SQL 场景可用 CTE 先取 ID 再 JOIN：
WITH random_ids AS ( SELECT TOP 1 id FROM your_table ORDER BY NEWID() ) SELECT t.* FROM your_table t INNER JOIN random_ids r ON t.id = r.id;
-
TABLESAMPLE(10 PERCENT)看似快，但它是按数据页抽样，不是按行，极小表可能抽不到数据，结果不可控 - 若必须精确控制比例（比如抽 5%），用窗口函数预计算总行数再过滤：
WITH sampled AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY NEWID()) AS rn, COUNT(*) OVER() AS cnt FROM users ) SELECT * FROM sampled WHERE rn <= cnt * 0.05;
注意COUNT(*) OVER()本身就要全表扫描，超大表应提前把总行数缓存到变量
去重后还要随机，怎么办
DISTINCT 和 ORDER BY NEWID() 不能共存，SQL Server 直接报错：“SELECT DISTINCT cannot be used with ORDER BY containing a non-aggregate expression”。
- 必须分两步：先用子查询或 CTE 去重，再在外层
ORDER BY NEWID() - 例如：
SELECT TOP 1 * FROM ( SELECT DISTINCT col1, col2 FROM your_table ) AS dedup ORDER BY NEWID();
- 如果去重字段多、数据量大，考虑加覆盖索引加速
DISTINCT阶段
真正容易被忽略的是：NEWID() 的“随机性”来自 GUID 生成器，它不保证均匀分布，但在实际抽样中偏差可接受；而性能陷阱往往不在语法本身，而在没意识到 ORDER BY NEWID() 背后是全表扫描+排序这一不可绕过的物理操作。
