newid()能实现随机排序，因其每次调用均生成全新、无序的uniqueidentifier值，sql server在order by中逐行实时计算并据此排序，等效于为每行打随机标签，从而打乱物理顺序。
NEWID() 为什么能实现随机排序
因为 NEWID() 每次调用都返回一个全新的、全局唯一的 uniqueidentifier 值，SQL Server 在 ORDER BY 中对这些值排序时，等效于给每行临时打一个不可预测的“随机标签”，再按该标签升序排——结果就是物理顺序被打乱，且只要数据集不变，每次执行都是不同顺序。
注意：它不生成“随机数”，而是利用 GUID 的高熵特性模拟随机性；不保证数学意义上的均匀分布，但对一般抽样、展示、测试足够可靠。
ORDER BY NEWID() 是最简可行写法
直接在查询末尾加 ORDER BY NEWID() 即可，无需子查询或变量：
SELECT TOP 10 * FROM Users ORDER BY NEWID();
常见误用是试图先用 NEWID() 生成列再排序，比如：
SELECT *, NEWID() AS rnd FROM Users ORDER BY rnd; -- 错！rnd 每行值不同，但 ORDER BY 时 rnd 已固定，看似随机实则无意义
正确逻辑是让 ORDER BY **实时调用** NEWID()，确保每行比较时都拿到新值。SQL Server 执行计划里能看到 NEWID() 被标记为 “Compute Scalar” 并参与排序键计算。
- 只适用于 SQL Server（含 Azure SQL）；PostgreSQL 用
ORDER BY RANDOM()，MySQL 用ORDER BY RAND() -
TOP N+ORDER BY NEWID()是取随机样本的惯用组合，比先加ROW_NUMBER()再过滤高效得多 - 大数据量（千万行以上）时性能会明显下降，因为必须生成全部 GUID 并排序；此时应考虑用
TABLESAMPLE或应用层抽样
NEWID() 不能防止结果重复，但排序本身不会产生重复记录
有人误以为 NEWID() 可能碰撞导致排序错乱——其实不会。uniqueidentifier 理论碰撞概率低于 2⁻¹²⁸，远低于硬件出错率；SQL Server 排序器也从不依赖值唯一性，即使两个 NEWID() 偶然相等，也只是让这两行相对顺序不确定（稳定排序下保持原序），不影响整体去重。
真正要“无重复记录”，靠的是源表主键或业务逻辑，不是 NEWID()。例如：
SELECT DISTINCT Name FROM Users ORDER BY NEWID(); -- 重复 Name 被去重，再随机排
如果目标是“随机选 N 条不重复的 ID”，只需确保源数据主键/唯一列存在，ORDER BY NEWID() 本身不会引入重复行。
替代方案：需要可复现随机序时不能用 NEWID()
NEWID() 每次执行都变，无法回溯或测试复现。若需固定随机顺序（如 A/B 测试分组、导出后校验），得换方式：
- 用时间戳+种子生成确定性哈希：
ORDER BY CHECKSUM(NEWID(), GETDATE())仍不可控；更稳妥是加整数种子列，用ORDER BY ABS(CHECKSUM([SeedColumn]) % 1000) - 在应用层生成随机数数组，传入 SQL 用
CASE WHEN id IN (...) THEN [rand_order]显式排序 - SQL Server 2022+ 支持
ORDER BY CRYPT_GEN_RANDOM(4)，但仍是不可复现的
真正可复现的随机序，本质要脱离运行时函数，靠预计算或外部控制。这点容易被忽略——看着是“随机排序”，实际需求可能是“可控随机”。
