order by newid()是sql server中唯一可靠的行级随机排序方式，因其每次调用生成新guid且在order by中逐行求值；而rand()单语句内仅计算一次，无法实现真正随机。
直接用 ORDER BY NEWID() 就能随机抽，但超过 5 万行就明显变慢，不是写法错，是 SQL Server 执行计划真会全表扫描+内存排序。
为什么 ORDER BY NEWID() 是唯一靠谱的随机排序方式
SQL Server 的 NEWID() 每次调用都生成新 GUID，且在 ORDER BY 中被强制逐行求值——这是它能“每行一个随机值”的底层机制。而 RAND() 在单条语句中只算一次，ORDER BY RAND() 实际等价于按一个固定数排序，结果永远不变。
常见错误包括：
- 把
SELECT *, NEWID() AS r FROM t ORDER BY r当成优化——多出一列没提速，还占内存 - 在视图或内联表值函数里用
NEWID()——SQL Server 明确报错：Invalid use of a side-effecting operator 'newid' within a function. - 事务中反复执行同一句
SELECT TOP 10 ... ORDER BY NEWID()，期望结果一致——不可能，每次都是全新随机，也无法回滚到“上次随机状态”
小表（
中小规模表直接用 TOP N + ORDER BY NEWID()，简单、可靠、结果可预期。
实操建议：
- 务必显式指定字段，避免
SELECT *拖慢宽表（尤其含TEXT/XML/JSON列） - 带条件时，确保
WHERE子句能走索引，例如WHERE status = 1 ORDER BY NEWID()，别让NEWID()把索引失效 - 若需去重后再随机，不能写
SELECT DISTINCT ... ORDER BY NEWID()——语法报错；应先DISTINCT落临时表，再对临时表ORDER BY NEWID()
示例：
SELECT TOP 5 id, name, created_at FROM users WHERE is_active = 1 ORDER BY NEWID();
大表（50 万+ 行）不加优化必卡死
全表扫描 + GUID 生成 + 内存排序，在大数据量下会让 Sort 运算符吃光内存，甚至触发磁盘溢出（Spill to TempDB），耗时从毫秒级跳到秒级甚至分钟级。
替代方案要分场景选：
- 主键连续或稀疏度可控 → 应用层生成随机 ID：查
MIN(id)和MAX(id)，程序用Random.Next(min, max+1)生成几个 ID，再WHERE id IN (…)查询 - 必须纯 SQL → 用 CTE 先抽 ID 再 JOIN：
WITH random_ids AS (SELECT TOP 10 id FROM t ORDER BY NEWID()) SELECT * FROM t JOIN random_ids ON t.id = random_ids.id - 接受近似比例（如“抽约 5%”）→ 用
TABLESAMPLE(5 PERCENT)，但它按数据页抽样，极小表可能返回空，且无法保证精确行数 - 要精确比例（如“刚好抽 5%”）→ 窗口函数预计算：
WITH sampled AS (SELECT *, ROW_NUMBER() OVER (ORDER BY NEWID()) AS rn, COUNT(*) OVER() AS cnt FROM t) SELECT * FROM sampled WHERE rn ；注意 <code>COUNT(*) OVER()本身就要全表扫描，超大表应提前缓存总行数到变量
封装进存储过程或函数时最容易漏掉的点
很多人把 SELECT TOP 1 * FROM t ORDER BY NEWID() 封进 TVF 就以为万事大吉，但有三个隐性陷阱：
- 函数内不能用
NEWID()——TVF 要求确定性，而NEWID()是非确定性函数，会直接报错 - 存储过程里多次调用同一随机语句，结果必然不同；若业务要求“本次会话内样本固定”，必须首次执行后把结果存入
#temp或@table变量，后续读缓存 -
WITH (NOLOCK)可加，但不解决性能问题，只降低阻塞；它不影响NEWID()的随机行为，也不规避排序开销
真正能复用的封装，是把“抽 ID”和“取数据”拆开，中间留出应用层干预空间——比如返回随机 ID 列表，由调用方决定要不要 JOIN、要不要加缓存逻辑。
