日常写 SQL 的时候，“随机查询一条表记录”这种需求其实比想象中多。抽奖、巡检、推荐位、测试数据抽取、A/B 实验分组，都会用到“从某张表里随机挑一条”的逻辑。最经典的写法就是ORDER BY NEWID()，简单到一行搞定，但它在大表上的表现可能让人心里没底。这篇文章我把两件事放在一起捋清楚：一是随机查询的几种主流实现方案，它们的原理、性能、适用场景到底怎么样；二是怎么把“随机查询”封装成自定义函数，让上层调用方只写一句SELECT就能拿结果，同时兼顾维护性和稳定性。适合刚接触 SQL Server、被各种随机需求弄得头疼的新手，也适合想把手头零散 SQL 整理成函数的老手。
1. 随机查询一条记录：主流方案与原理拆解
1.1 被误解的“最短路”：ORDER BY NEWID() 的性能真相
NEWID()是 SQL Server 生成 GUID 的系统函数。SELECT TOP 1 * FROM Users ORDER BY NEWID()的执行逻辑是：先扫描全表拿到所有行，然后为每一行生成一个 GUID，最后按 GUID 排序取第一条。GUID 的随机性非常好，所以结果在概率上是均匀的，这一点在数据量小的时候无可挑剔。
问题出在排序本身。千万级甚至百万级的大表，每一行都要计算一次NEWID()，整表排序的 CPU 开销和 TempDB 空间占用都很夸张。我在实际项目里见过有人把这条语句直接写进核心接口，数据量一上来，数据库 CPU 直接飙到高位，接口超时。如果你只是在一个千级或者万级的表上做一次性查询，ORDER BY NEWID()完全可以继续用；但表一旦上了量级，就要慎重了。
一个容易忽略的点是：NEWID()是不确定函数，每次执行都会生成新的 GUID，所以同样的查询每次大概率会返回不同记录。这种“不确定性”既是我们想要的随机效果，也意味着 SQL Server 不会对这类查询做结果缓存，每次调用都是实打实的全表计算。
1.2 自增主键下的“随机数偏移”玩法
如果表有自增主键，性能最好的方案之一就是“随机数偏移法”。思路很简单：先拿到主键的最小值和最大值，在这个区间内随机生成一个数，然后取主键大于等于这个随机数的第一条记录。
DECLARE @minId INT = (SELECT MIN(UserId) FROM dbo.Users); DECLARE @maxId INT = (SELECT MAX(UserId) FROM dbo.Users); DECLARE @randId INT = @minId + CAST(RAND() * (@maxId - @minId) AS INT); SELECT TOP 1 * FROM dbo.Users WHERE UserId >= @randId ORDER BY UserId;这个方案的核心优势是每次都走主键索引的局部范围查找，无论表多大，只要MIN和MAX有缓存或者能走索引快速拿到，查询都很快。百万级表通常也能在几十毫秒内返回，相比ORDER BY NEWID()的整表排序，性能是质的飞跃。
但缺点也要说清楚：随机性的均匀程度依赖主键的连续性。如果表里删除过大量记录，主键会出现空洞。举个例子，某表只剩 1、2、1000、1001 四条记录，随机数范围是 1～1001，那随机数落在 3～1000 区间时，查询都会取到 1000 这条记录，导致 1000 和 1001 被选中的概率远远大于 1 和 2。所以这个方案更适合主键连续或者删除操作很少的业务表。如果主键空洞没办法避免，又想用这个方案，可以配合后续要讲的预计算随机键或者应用层策略来做补偿。
1.3 TABLESAMPLE 与 OFFSET/FETCH：补充手段各有脾气
TABLESAMPLE是 SQL Server 提供的采样语法，基于数据页进行抽样。写起来非常简洁：
SELECT TOP 1 * FROM dbo.Users TABLESAMPLE (1000 ROWS);这里的 1000 是“目标行数”，不是精确值。SQL Server 会按页采样，返回的行数可能多也可能少，小表甚至可能返回 0 行。所以它适合大表抽样统计，不适合“必须返回一条”的场景。如果非要用它拿一条，就得在外面包一层循环，一直重试直到取到非空结果，这在实际业务里有点鸡肋。
OFFSET/FETCH是另一种思路：先统计总行数，随机生成一个偏移量，然后按主键排序跳过这么多行，取下一行。
DECLARE @total INT = (SELECT COUNT(*) FROM dbo.Users); DECLARE @offset INT = CAST(RAND() * @total AS INT); SELECT * FROM dbo.Users ORDER BY UserId OFFSET @offset ROWS FETCH NEXT 1 ROWS ONLY;这个方案的随机性是均匀的，因为它把每条记录看成等概率的位置。性能上，它不需要全表排序，但OFFSET在底层需要扫描并跳过前面那些行，所以数据量大的时候依然会变慢。中等数据量（几万到几十万）用起来比较顺手，百万级以上就别强求了。
还有一种应用层思路：先把主键列表查询出来放到应用内存里，在应用端随机挑一个 ID，再回表拿完整记录。这个方案最适合小表或者对“不等概率随机”有特殊需求的场景，比如加权随机。应用层做加权随机极其方便，SQL 端只需要负责按 ID 精确取一条数据。
1.4 选型对比：一张表看清怎么选
| 实现方式 | 随机性 | 性能量级 | 适用场景 |
|---|---|---|---|
| ORDER BY NEWID() | 优 | 小表尚可，大表差 | 小表、临时脚本、一次性需求 |
| 主键随机数偏移 | 良（依赖主键分布） | 优 | 自增主键、删除少、需要高性能 |
| TABLESAMPLE | 一般（页级随机） | 优 | 大表抽样、允许结果偏差 |
| OFFSET/FETCH | 优 | 中等数据量尚可 | 需要均匀随机的中等表 |
| 应用层 ID 列表随机 | 优 | 看 ID 列表大小 | 小表、接口直连、加权随机 |
没有哪种方案是万能的。我自己的选型习惯是：先问表多大、数据分布大概什么情况，再问业务对“严格均匀”有没有要求。两个问题问完，答案基本就清楚了。
2. 自定义函数封装：从“随手写”到“收口管理”
2.1 三类自定义函数，先分清楚再动手
SQL Server 的自定义函数大体分三类：
第一类是标量函数，返回单个值，比如一个 UserId 或者一个计算后的金额。调用方式最直观，SELECT dbo.GetRandomUserId()就能拿到一个随机 ID。
第二类是内联表值函数，返回的是一个表，函数体是单条SELECT语句。它本质上相当于一个“参数化视图”，调用方可以像查普通表一样SELECT * FROM dbo.GetRandomUser()。因为函数体会被优化器展开到外部查询里，性能往往不错，也是我封装随机查询时最推荐的类型。
第三类是多语句表值函数，函数体里可以先声明表变量，然后写多条语句把数据填进去，最后RETURN这个表变量。它最灵活，但表变量没有统计信息，大数据量 JOIN 时优化器容易误判行数，性能可能出问题。
用生活类比来说：标量函数像自动售货机，投币就掉一个商品；内联表值函数像餐厅菜单上的套餐，你说要什么，后厨按配方现做；多语句表值函数像预制菜流水线，先在你眼前加工好一批再给你，但加工过程本身有额外开销。
| 类型 | 返回内容 | 函数体 | 性能特点 | 适用场景 |
|---|---|---|---|---|
| 标量函数 | 单个标量值 | BEGIN/RETURN | 逐行调用时有损耗 | 简单单值查询 |
| 内联表值函数 | 表 | 单条 SELECT | 可下推谓词，表现好 | 参数化查询、随机取行 |
| 多语句表值函数 | 表 | 多条语句 | 表变量无统计信息 | 复杂加工、数据量不大 |
2.2 封装随机查询函数：设计原则与示例
为什么要封装？核心就三个字：收口。随机算法如果散落在各个存储过程、业务代码里，将来想换方案，要翻遍所有调用点。封装成函数之后，上层只面对一句SELECT，算法再怎么换都不影响业务侧。
封装时我一般遵守几个原则：优先内联表值函数；过滤条件尽量参数化；函数名要见名知意；不要做超出“读取”逻辑的事。比如下面这个函数，封装的是“按年龄范围随机取一条用户”：
CREATE OR ALTER FUNCTION dbo.GetRandomUserByAgeRange( @MinAge INT, @MaxAge INT ) RETURNS TABLE AS RETURN ( SELECT TOP 1 UserId, UserName, Age, RegisterTime FROM dbo.Users WHERE Age BETWEEN @MinAge AND @MaxAge ORDER BY NEWID() ); GO调用方写起来非常清爽：
SELECT * FROM dbo.GetRandomUserByAgeRange(30, 40);如果将来发现ORDER BY NEWID()在大表上扛不住，只需要在这个函数内部把算法换成主键偏移法，或者换别的实现，所有调用方都不需要感知。这就是封装带来的直接价值。
2.3 函数体内的随机函数限制：NEWID() 和 RAND() 的差别
很多新手以为随机函数都不能放进自定义函数里，这是个误解。SQL Server 对函数体内可用的系统函数有限制，但NEWID()通常是可以用的。真正容易踩坑的是RAND()：在很多 SQL Server 版本里，把RAND()放进 UDF 会直接报错，提示类似“Invalid use of a side-effecting operator 'rand' within a function”。原因是RAND()被归类为带副作用的运算符，UDF 不能使用。
这意味着，如果需要在函数内部生成一个范围内的随机整数，应该用NEWID()配合校验和来绕过：
CAST(ABS(CHECKSUM(NEWID())) % 100 AS INT)这段代码的思路是：先拿NEWID()生成一个随机 GUID，再用CHECKSUM()把它变成一个整数，ABS()取绝对值，最后% 100映射到 0～99 区间。这是 SQL Server 函数体内比较通用的随机整数生成技巧。
还有一种更稳妥的思路：在函数外算好随机数，作为参数传进函数。比如用RAND()在调用端生成随机偏移量，再传给一个按偏移量取记录的函数。这样既绕开了限制，又把“随机”这个决定权留给了调用方，各有适用场景。
3. 完整实操：建表、灌数据、封装、验证一条龙
3.1 准备一张测试表并生成模拟数据
手工敲几条数据没法验证随机效果，我直接用递归 CTE 生成一万条测试数据。先建一张用户表：
CREATE TABLE dbo.Users ( UserId INT IDENTITY(1,1) PRIMARY KEY, UserName NVARCHAR(50) NOT NULL, Age INT NOT NULL, RegisterTime DATETIME NOT NULL );生成数据的思路很简单：用递归 CTE 生成 1 到 10000 的序列，然后组装用户名、随机年龄和随机注册时间。注意递归 CTE 默认最大递归次数是 100，必须加OPTION (MAXRECURSION 0)解除限制。
;WITH cte AS ( SELECT 1 AS n UNION ALL SELECT n + 1 FROM cte WHERE n < 10000 ) INSERT INTO dbo.Users (UserName, Age, RegisterTime) SELECT N'User' + CAST(n AS NVARCHAR(10)), ABS(CHECKSUM(NEWID())) % 50 + 18, DATEADD(DAY, -ABS(CHECKSUM(NEWID())) % 3650, GETDATE()) FROM cte OPTION (MAXRECURSION 0);年龄范围设计成 18～67 岁，因为ABS(CHECKSUM(NEWID())) % 50生成 0～49，再加 18 就是 18～67。注册时间则是过去 10 年内的随机一天。执行完后用SELECT COUNT(*) FROM dbo.Users;验证一下，应该能拿到 10000。
3.2 编写标量函数：返回一条随机 UserId
标量函数的特点是简单直接。我们把“随机取一个 UserId”封装成函数：
CREATE OR ALTER FUNCTION dbo.GetRandomUserId() RETURNS INT AS BEGIN RETURN ( SELECT TOP 1 UserId FROM dbo.Users ORDER BY NEWID() ); END GO调用的时候必须带模式前缀，直接写GetRandomUserId()会报错：
SELECT dbo.GetRandomUserId() AS RandomUserId;多执行几次，返回值大概率每次都不一样。这是因为NEWID()在每次调用时都会重新生成随机 GUID，排序结果自然不同。如果连续几次都返回同一个 ID，也不是没有可能，概率是一万分之一，不用慌。
3.3 编写内联表值函数：返回整条随机记录
只拿一个 ID 往往不够，业务里通常还要把整条记录一起返回。这时候内联表值函数更合适：
CREATE OR ALTER FUNCTION dbo.GetRandomUser() RETURNS TABLE AS RETURN ( SELECT TOP 1 UserId, UserName, Age, RegisterTime FROM dbo.Users ORDER BY NEWID() ); GO调用方式跟查表一样：
SELECT * FROM dbo.GetRandomUser();如果想按条件随机，比如只要 30～40 岁的用户，可以继续参数化：
CREATE OR ALTER FUNCTION dbo.GetRandomUserByAgeRange( @MinAge INT, @MaxAge INT ) RETURNS TABLE AS RETURN ( SELECT TOP 1 UserId, UserName, Age, RegisterTime FROM dbo.Users WHERE Age BETWEEN @MinAge AND @MaxAge ORDER BY NEWID() ); GO调用时传参数就行：
SELECT * FROM dbo.GetRandomUserByAgeRange(30, 40);如果你用的 SQL Server 版本较老，不支持CREATE OR ALTER，可以把语句改成先DROP FUNCTION再CREATE FUNCTION，效果是一样的。注意函数定义要求是批处理的第一条语句，所以每段定义之间最好用GO分隔。
3.4 随机性验证：跑 100 次看分布
函数封装好了，最好验证一下它到底是不是“真随机”。我来提供一个简单的验证思路：循环调用 100 次，把每次拿到的 UserId 按区间分组统计。
DROP TABLE IF EXISTS #RandomResult; CREATE TABLE #RandomResult (UserId INT); DECLARE @i INT = 1; WHILE @i <= 100 BEGIN INSERT INTO #RandomResult (UserId) SELECT UserId FROM dbo.GetRandomUser(); SET @i = @i + 1; END; SELECT CASE WHEN UserId <= 2500 THEN '1区(1-2500)' WHEN UserId <= 5000 THEN '2区(2501-5000)' WHEN UserId <= 7500 THEN '3区(5001-7500)' ELSE '4区(7501-10000)' END AS RangeName, COUNT(*) AS Cnt FROM #RandomResult GROUP BY CASE WHEN UserId <= 2500 THEN '1区(1-2500)' WHEN UserId <= 5000 THEN '2区(2501-5000)' WHEN UserId <= 7500 THEN '3区(5001-7500)' ELSE '4区(7501-10000)' END;如果随机算法没问题，四个区间的次数应该大致接近 25 左右，不会出现某个区间独占 80 次的极端情况。这个验证方法不只适用于一万行的测试表，换成任何表都可以快速确认随机策略是否可靠。
4. 性能损耗、常见问题与排查实录
4.1 大表随机查询优化：预计算随机键与主键偏移法
表一大，ORDER BY NEWID()基本靠不住。除了前面说的主键偏移法，还有一个以空间换时间的思路：预计算随机键。简单说，就是单独建一张表，原表每个 ID 对应一个随机键，随机键用NEWID()初始化。查询时只需要对随机键排序取最小的一条，再回原表拿完整数据。
CREATE TABLE dbo.UserRandomKey ( UserId INT PRIMARY KEY, RandomKey UNIQUEIDENTIFIER DEFAULT NEWID() ); INSERT INTO dbo.UserRandomKey (UserId, RandomKey) SELECT UserId, NEWID() FROM dbo.Users;这个方案的前提是，随机表需要定期刷新，否则每次ORDER BY RandomKey取到的都是同一个最小值，随机就失效了。比较常见的做法是：每天或者每隔一段时间更新整张随机表的RandomKey，适合类似“每日抽签”这种低实时性要求但高频调用的场景。
如果不想维护额外表，主键偏移法是更轻量的选择。记得把MIN(UserId)和MAX(UserId)的结果缓存下来，不必每次查询都去扫一遍。缓存可以由应用层负责，也可以放到一个专门的配置表里，周期性更新。这个优化对高并发接口来说非常有用。
4.2 标量函数与表值函数的使用边界：别让封装变成性能黑洞
标量函数用起来方便，但有个隐藏的大坑：把它写在 SELECT 列表里时，SQL Server 会对结果集的每一行都调用一次函数。比如这种写法：
SELECT dbo.GetRandomUserId() FROM dbo.BigTable;表面上看没什么问题，实际上每一行都会触发一次随机查询，等于是给每行数据都做了一遍全表扫描加排序，性能灾难就这样产生了。集合型操作里尽量别用标量函数，换成内联表值函数做 JOIN，让优化器有更多发挥空间。
内联表值函数在这方面表现更好，因为它像视图一样被展开进主查询，外层查询的过滤条件有机会下推。多语句表值函数则刚好相反，内部用的是表变量，没有统计信息，外部 JOIN 时优化器可能拿不到真实行数，执行计划可能走歪。所以我常说的一句话是：能用内联表值函数解决的问题，别用多语句表值函数。
还有一个边界必须知道：函数体里不能修改数据库表，只能操作表变量；也不能执行动态 SQL。如果你发现自己要在函数里写 UPDATE，多半是设计思路出了问题，应该改成存储过程而不是函数。
4.3 常见的三个“隐形坑”与排查思路
踩坑是难免的，我把遇到最多的几个问题整理成速查式提醒。
第一个坑：调用函数时不带模式前缀。SQL Server 的自定义函数调用时必须用dbo.GetRandomUserId()这样的写法，直接写GetRandomUserId()会报“不是可识别的内置函数名”。这个报错对新手特别迷惑，因为存储过程调用时往往可以不带前缀，函数却不行。
第二个坑：TOP 1不写ORDER BY，以为就能随机。这是逻辑错误。TOP 1只是“取前一条”，如果没有排序字段，SQL Server 通常按物理扫描顺序取一条。表数据不变的情况下，每次可能都返回同一行，根本不是随机。任何随机查询都必须在函数体内带上ORDER BY NEWID()。
第三个坑：RAND()放进 UDF。前面已经讲过，RAND()在函数内部会被拒绝，报错信息又长又绕。解决办法是改用ABS(CHECKSUM(NEWID())) % N，或者在函数外面算好随机值，再作为参数传给函数。
如果函数创建时报错，先检查你当前的版本是否支持CREATE OR ALTER。SQL Server 2016 SP1 以上版本才支持这个语法，老版本需要先 DROP 再 CREATE。
4.4 随机查询方案速查表
| 需求场景 | 推荐方案 | 注意点 |
|---|---|---|
| 数据量小（千级以内），随手写 | ORDER BY NEWID() | 最简单，无需优化 |
| 自增主键、删除记录少 | 主键随机数偏移 | 缓存 MIN/MAX 可进一步提速 |
| 数据量大、允许结果偏差 | TABLESAMPLE | 小表可能返回 0 行 |
| 中等数据量、要求均匀随机 | OFFSET/FETCH | 偏移扫描有开销 |
| 高并发、定期随机抽取 | 预计算随机键 + 定时刷新 | 注意刷新策略，避免取到固定行 |
我自己在实际项目里最常用的是主键偏移法和预计算随机键。主键偏移法胜在轻量，预计算随机键胜在可控，尤其是需要保证每次结果都不重复时，可以在刷新逻辑里做一些状态标记。接口类的随机抽取，我还喜欢把随机决策放到应用层：应用端生成随机 ID，SQL 只需要做一次精确点查，这种模式在高并发下最稳。
这次重新梳理，最大的体会是 SQL 没有银弹，随机查询也一样。方案的取舍永远取决于表的数据量、主键分布和业务容忍度。我见过有人在核心接口上直接写ORDER BY NEWID()导致数据库 CPU 飙满，也见过有人为了追求绝对均匀，在千万级表上绕了很大一圈，最后发现业务根本不在乎那点概率偏差。我的习惯是先问清楚两个问题：表有多大？随机结果是否需要严格均匀？问完之后选方案，再把方案封装成函数收口，后续维护成本会低很多。最后分享一个小技巧：如果随机查询用到了主键 ID 偏移，记得把MIN和MAX缓存到应用层或者配置表，周期性刷新，能进一步减少数据库的压力。
