SQL随机抽样性能优化：从ORDER BY RANDOM陷阱到高效方案

1. 为什么“ORDER BY RANDOM()”会成为性能陷阱

1.1 一条看起来无害的 SQL

很多人在第一次写随机抽样时，都会下意识敲出这样一行代码：

SELECT * FROM orders ORDER BY RANDOM() LIMIT 100;

逻辑上，这行SQL一点毛病都没有：给每一行生成一个随机数，然后按随机数排序，最后取前100条。数据量小的时候，比如几千行，响应时间是毫秒级的，根本察觉不到问题。可一旦表里有几百万甚至上千万行，这条SQL就可能让数据库CPU瞬间飙满，查询跑上十几秒，把整个业务拖垮。

我见过不少线上事故，起因就是某个后台管理系统加了一个“随机展示10条”的功能，开发同学图省事直接写了ORDER BY RANDOM()。上线初期数据量小，一切正常；三个月后表数据过千万，每次打开页面都卡到超时，最后DBA查慢查询日志，才发现这条SQL每次都在给全表数据做随机排序。

1.2 执行计划拆解：随机排序为什么慢

要理解它为什么慢，得把它拆成两步看，一是“生成随机数”，二是“排序”。先说排序本身，数据库要按随机值把全表数据重新排一遍，这是一个标准的排序操作，时间复杂度是 O(N log N)。表越大，排序成本越高，而且它没法走索引，因为排序键根本不是业务字段，而是每次执行时临时计算出来的值。

更麻烦的是随机数生成这个步骤。对每一行，数据库都要调用RANDOM()函数。这个函数本身不贵，但问题是它破坏了数据库的预读和批量处理能力。很多数据库优化器对“非确定性函数”非常保守，它不知道RANDOM()下次调用会返回什么，所以无法提前做任何优化，只能老老实实把每一行都拉出来、逐行计算、再全部排序。

有人可能会说：“我就取100条，排序完只取前面一小部分，能不能提前停止？”理论上可以，但绝大多数数据库的排序算子做不到。优化器不会因为你写了LIMIT 100就改成“边排边取”，它还是会先算出完整的排序结果，再截取前100行。这意味着你为了取100条随机数据，把整张表的随机排序结果都算出来了，大量的计算被白白浪费掉。

1.3 不同数据库的实现差异

这里还得说一句大实话：不同数据库对ORDER BY RANDOM()的处理方式并不完全一样。某些数据分析型数据库有分布式并行能力，可能表现稍好；某些内存型数据库因为数据全在内存，也还能扛得住；而更多的传统关系型数据库，尤其是面向事务处理的场景，碰上这条SQL基本就是灾难。

有的数据库支持“采样算子”，可以直接从存储引擎层面抽取数据块；有的数据库只支持标准的ORDER BY RANDOM()，毫无优化空间；还有一些数据库要求随机函数必须带种子参数，否则每次执行结果完全不可复现。这些差异意味着，你不能拿着一套SQL到处跑，必须针对你实际使用的数据库来做适配。这个点后面讲具体方案时还会展开。

我个人的判断标准很简单：如果表的数据量超过10万行，且这个抽样查询会被高频执行，那ORDER BY RANDOM()就应该被列入禁止清单，在代码评审阶段就把它拦下来。

2. 动手前先想清楚：你要的是哪种“随机”

2.1 抽样目标决定方案

很多人一上来就写SQL，却忘了先想一个问题：你到底需要什么样的随机样本？这个问题的答案直接决定了技术选型。

常见需求其实分三类。第一类是“从全表均匀抽N条”，比如做数据分析时想抽一个代表性样本做探索性分析，这时候样本要尽量均匀，不能偏向某个分区或某段主键。第二类是“随机展示N条给用户”，比如首页推荐、热门文章随机看，这类需求对均匀性要求没那么高，反而更看重响应速度和用户体验。第三类是“按比例抽样”，比如抽取全表1%的数据做质量校验，这类需求关注的是抽样比例准确，而不一定在乎每一条的具体命中概率。

这三种需求对应三种完全不同的实现路径。有些方案虽然快，但抽样不均匀；有些方案虽然均匀，但实现复杂、响应慢。先搞清楚业务上到底要什么，再去选方案，才不会走弯路。

2.2 三种抽样的数学模型

再往深一层说，随机抽样有三种基本的数学模型。

一是“简单随机抽样”，每个样本被抽中的概率完全相等，且每抽一次都是独立事件。这是最理想的抽样方式，但实现成本最高，因为往往需要对全表做一次扫描或者排序。

二是“系统抽样”，也叫等距抽样。先随机选一个起点，然后每隔固定间隔取一个样本。比如表有100万行，想抽1000条，就每隔1000行取一条。这种方式的优点是快，缺点是如果表的主键分布有周期性规律，抽样结果会带上周期偏差。

三是“整群抽样”，先把数据分成若干组或块，然后随机抽几个整组，组内全部保留。这种方式速度极快，因为抽中一个块就能拿到一批数据，但如果块内数据相关性很高，样本代表性会大打折扣。

理解了这三种模型，你就知道为什么ORDER BY RANDOM()在某些场景下其实是“用大炮打蚊子”。它实现的是最简单的简单随机抽样，但付出的代价却是全表排序。而很多业务场景，比如用户端随机展示，根本不需要这么严格的均匀性，用整群抽样足够了。

2.3 不要把“随机”和“排序”绑在一起

还有一个思维误区必须纠正：很多人觉得“要随机”就一定要“排序”。其实不是。

随机抽样的本质是“让每个候选行有各自的命中概率”，而不是“把全表排成一个随机顺序”。你完全可以不排序，只靠概率判断就能完成抽样。举个例子，你可以对每行计算一个随机数，然后只保留随机数小于某个阈值的那部分行，这样虽然输出的顺序还是原来的物理顺序，但选出来的行已经是随机的了。

这个思路非常关键。它能让你把 O(N log N) 的排序问题降级为 O(N) 的筛选问题，在数据量很大时，性能差距是指数级的。后面要讲的几个高效方案，本质上都是在这个思路上做文章。

3. 高效随机抽样的核心实现方案

3.1 表抽样：用数据库原生能力

先聊一个很多人没注意到的原生能力：表抽样（TABLESAMPLE）。

它长这样：

SELECT * FROM orders TABLESAMPLE SYSTEM (1);

这条SQL的意思是，从存储层面直接抽取约1%的数据块。数据库不需要逐行判断，直接从磁盘上挑几个数据页返回，速度极快。

注意，TABLESAMPLE SYSTEM 是按“存储块”为单位抽的，不是按“行”为单位抽的。所以抽出来的数据在业务上不一定均匀，比如某个数据页里恰好全是同一批用户的订单，抽样结果就会有偏差。因此它非常适合数据量极大、对均匀性要求不高的场景，比如快速看一眼数据长什么样、验证一下字段格式，或者做全量数据的粗略统计。

还有一个变体叫TABLESAMPLE BERNOULLI，它是按行为单位逐行判断是否命中，均匀性更好，但性能比 SYSTEM 差一些，本质上是把所有行都扫一遍。如果你的数据库支持 BERNOULLI 且抽样比例不大，优先选它；如果追求极致性能，选 SYSTEM。

这个方案最大的优势是代码极简、性能极好，缺点是它不能接受任意 WHERE 条件。你想抽“最近一个月下单的用户”，TABLESAMPLE 帮不上忙，因为抽样发生在存储层，还没到过滤条件那一步。所以这个方案适合“物理上随机抽”，不适合“逻辑上随机抽”。

3.2 主键区间偏移法

接下来是实战中最常用、也最推荐优先尝试的方案：主键区间偏移法。

思路非常简单。假设orders表的主键是自增 id，最小值为1，最大值为1000万。想抽100条，那就先随机生成100个介于1到1000万之间的目标 id，然后直接去主键索引里查这些 id 对应的行。

SELECT * FROM orders WHERE id IN ( SELECT (1 + RANDOM() * 9999999)::int FROM generate_series(1, 100) );

这里的generate_series(1, 100)用来生成100个序号，每个序号都对应一个随机跳跃的目标 id。执行时，数据库只需要按主键索引做100次等值查询，理论上速度是毫秒级的。

这个方案的缺点是，它要求主键是数字且接近连续分布。如果表里经常有删除操作，主键会出现空洞，抽样结果会偏向主键区间密度更高的部分。怎么解决？先把MAX(id)和MIN(id)查出来，然后随机生成区间内的id，查不到的跳过。只要空洞占比不高，问题不大。

再退一步，如果主键是UUID，这个方法就没法用了。Guideline很简单：主键是自增数字，优先用这个方案；主键是业务字符串或UUID，往下看别的方案。

3.3 随机排序+预计算的物化方案

如果你的业务场景是“每次访问都要随机展示一批内容”，比如资讯App的“猜你喜欢”模块，那么可以换一个思路：提前算好随机顺序，存起来，查询时直接用。

具体做法是给表加一个随机排序列，比如random_sort，类型是 double。首次初始化时，用RANDOM()给每一行赋一个随机值：

UPDATE articles SET random_sort = RANDOM();

然后在这个列上建索引：

CREATE INDEX idx_articles_rand ON articles (random_sort);

之后每次查询就是一次普通的索引扫描：

SELECT * FROM articles ORDER BY random_sort LIMIT 10;

这个方案的精妙之处在于，它把“每次查询时的随机排序”变成了“一次建好、多次复用”的索引顺序。查询时数据库沿着索引顺序往后扫，扫到10条就停，没有全表排序。性能极好，而且支持正常的 WHERE 过滤。

缺点也明显：随机排序是固定的，不是每次访问都重新随机。所以同一批内容会被反复展示，直到你手动重新UPDATE一次随机值。解决办法也很简单，定时任务每隔一段时间刷新一次，或者在高频访问的时段之外悄悄重置。

这个方案牺牲了一点点“动态随机性”，换来了极高的查询性能。在用户端随机展示场景，这个取舍非常划算。

3.4 组合键与复杂过滤条件

前面几个方案都有各自的限制。如果业务表不仅主键不连续，还要求苛刻的过滤条件，怎么随机抽样？

我常用的方案是“两阶段法”。先查目标范围内符合条件的所有候选主键，抽样后回表。

-- 第一步：找出符合条件的所有id SELECT id FROM orders WHERE status = 'paid' AND created_at >= NOW() - INTERVAL '7 days';

如果符合条件的行数不多，比如几万行，可以直接在应用层随机打乱取100个 id，再回表查。如果符合条件的行数很大，比如几百万行，那就在SQL里再做一次子查询抽样：

SELECT * FROM orders WHERE status = 'paid' AND created_at >= NOW() - INTERVAL '7 days' ORDER BY RANDOM() LIMIT 100;

你可能会说：“这不还是ORDER BY RANDOM()吗？”对，但前提变了：这个SQL的执行范围已经被前面的 WHERE 条件缩小到了几百万行以内的候选集。在某些数据库上，对百万行排序已经不算轻松，但比全表千万行排序好得多。如果再叠加“先缩小候选集，再对候选集做随机排序”的策略，多数场景都能接受。

更进一步，如果你能接受近似随机，还可以先对候选集做一次预聚合，比如“按用户分组后随机抽用户，再从每个用户下抽订单”，这就是后面第4节要讲的分桶思路。

4. 大数据量下的进阶策略

4.1 分桶抽样：先抽块再抽行

当数据量大到“即使扫一遍全表都很心疼”的程度，就要考虑分桶抽样了。

分桶抽样的核心思想是两层抽样。先把数据按照某个业务维度切成若干个桶，比如按日期切成每天一桶，按用户ID哈希切成100个桶。第一层，随机抽取其中几个桶；第二层，在抽中的桶内部再做行级随机抽样。

这样做的好处是，你不需要访问所有数据。假设每天的数据是一个独立分区，你随机抽了3天的分区，查询只需要扫描这3天分区的大小，而不是全表。数据量越大，这种策略的收益越明显。

SQL实现也很直接。以日期分区表为例：

SELECT * FROM orders WHERE order_date IN ( SELECT order_date FROM orders GROUP BY order_date ORDER BY RANDOM() LIMIT 3 ) ORDER BY RANDOM() LIMIT 100;

这里先按天分组，随机抽出3个日期，然后只在这3天里面随机抽100条。实际执行时，数据库优化器会优先裁剪分区，只扫描被选中的3个分区的数据。

分桶抽样的局限性在于，它会牺牲一定的均匀性。如果某个桶的数据量远大于其他桶，那么该桶数据被抽中的概率相对更高。解决办法就是“概率加权”，让大桶被选中的概率按数据量比例放大，但这需要你在应用层事先统计好各桶大小，复杂度会上升。

4.2 可复现抽样：固定随机种子

很多数据分析场景要求抽样结果可复现——你今天抽的样本，明天重跑一次SQL，拿到的应该是同一批数据。这样才能保证分析结论可追溯、可评审。

ORDER BY RANDOM()做不到这一点，因为它每次执行都生成全新的随机序列。解决办法是用可带种子的随机函数。

在一些数据库里有SETSEED()这类函数，调用一次之后，后续的RANDOM()调用序列就能稳定复现：

SELECT SETSEED(42); SELECT * FROM orders ORDER BY RANDOM() LIMIT 100;

固定种子的价值不只是复现，它还能让你做A/B对比实验时保持变量可控。比如你分别用种子1和种子2抽取两组样本，各组内部的分布保持一致，对比实验结果会更有说服力。如果不固定种子，跑十次同样的查询得到十批不同的样本，实验结论就很难归因。

这个方案本身很简单，但很多人不知道，而且不同数据库的语法差异不小，换库时要专门确认。建议把固定种子抽样的SQL封装成一个存储过程或函数，统一管理。

4.3 小表驱动大表的反向抽取技巧

最后分享一个我比较喜欢用的偏门思路：小表驱动大表。

假设你要从10亿行的大表里随机抽100条。直接在大表上做随机排序，哪怕有索引也扛不住。换个思路：如果你有另一张小表，它记录了大表的“数据块分布”或“分区概要”，那就可以先在小表上随机抽取，再用抽中的位置信息去大表精确定位。

举个例子，一个表按用户维度分成了1000个数据分片，分片信息存在table_shards里，每行记录一个分片的范围和统计信息。现在想随机抽100个用户，逻辑是先随机抽若干分片，再从分片里抽用户：

-- 先抽分片（小表，几千万行，但远小于大表） SELECT shard_id FROM table_shards ORDER BY RANDOM() LIMIT 5; -- 再回大表按分片范围抽数据 SELECT * FROM big_table WHERE shard_id IN (...) ORDER BY RANDOM() LIMIT 100;

这种分层反向抽取思路的本质，是把“在巨大集合上随机”降维成“在较小集合上随机，再通过索引回查”。它适用于那些有天然分层结构的表，比如按租户、按地区、按时间分片的业务表。在实际项目中，我多次靠这个思路救活了慢查询，值得诸位尝试。

5. 常见问题与避坑清单

5.1 主键不连续怎么办

很多开发者在自增主键上用了“随机偏移法”，抽出来的结果总数老是少于预期，有时甚至只有预期的五六成。原因是表里有大量历史删除产生的空洞。

解决思路有几种。第一，先查MAX(id)和MIN(id)，在区间内随机生成N个点，然后WHERE id IN (...)过滤，命中多少算多少；如果觉得太少就再补抽。第二，如果空洞特别大，不如换成“连续行号法”，就是先给表临时加一个连续行号，随机生成行号区间再取数。连续行号可以来自窗口函数：

WITH numbered AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at) AS rn FROM orders ) SELECT * FROM numbered WHERE rn BETWEEN 500000 AND 500000 + 100;

这个方案先做一次全表扫描生成行号，然后用BETWEEN精确切一段出来。它的效率比全表排序高，前提是你不在乎这段时间内的创建时间分布是否均匀。注意，如果业务要求严格均匀，连续行号法不如直接基于自增主键的方法。

5.2 抽到的样本偏了：如何校验

有一种情况很容易被忽视：你用了某个抽样SQL，看着速度很欢乐，但抽出来的样本实际上严重有偏，直接拿去做了统计，最后得出错误结论。怎么校验抽样质量？

一个很简单的办法是拿样本和全量做对比。对某个关键指标，比如订单金额字段，分别计算全表的平均值、标准差，再计算样本的平均值、标准差，两者差距小于5%基本可以接受。如果样本均值偏离超过10%，那就要怀疑抽样方法了。

我列一个常用的校验SQL模板：

-- 全表统计 SELECT AVG(amount), STDDEV(amount) FROM orders; -- 样本统计 WITH sample AS ( SELECT id FROM orders ORDER BY RANDOM() LIMIT 10000 ) SELECT AVG(o.amount), STDDEV(o.amount) FROM orders o JOIN sample s ON o.id = s.id;

多测几次，观察样本统计值是否稳定。如果波动很大，说明抽样方案不够稳定，多半是用了整群抽样但群内方差太大。

5.3 上线前必做的三件事

做任何抽样功能之前，我建议按这三步自检，能躲掉大部分坑。

第一，确认表的数据量级和增长趋势。是10万行还是1000万行？增长快不快？这直接决定要不要做优化，以及做到什么程度。数据量还在万级时，没必要上复杂的抽样方案；数据量已经到了千万级，就必须用第3、4节里的方案了。

第二，做一次执行计划审查。单独跑一遍目标SQL，看执行计划里有没有Sort算子，排序的估算行数是多少。如果排序行数超过100万，多半要优化；如果排序行数只有几千，那ORDER BY RANDOM()也没那么可怕。

第三，验证抽样结果的分布。像5.2节那样，把样本的关键字段和全表做对比，确认抽样不会显著倾斜。这一步在数据分析场景尤其重要，很多业务侧同学只关注查询快不快，却忽略了样本质量，最后分析结论不可靠，锅还得你背。

5.4 各方案选型对比参考

很多朋友问过我，这么多方案到底该选哪个？我把主要方案的适用场景和性能特征整理成了一张表，方便各位对照选择。

选型的总体思路是：先看数据量，再看均匀性要求，最后看实现成本。绝大多数场景，主键区间偏移法和预计算随机列已经够用了；只有到亿级数据，才需要考虑分桶抽样这类更复杂的策略。

6. 从一次线上事故聊到的一点体会

几年前我接手过一个统计报表系统，每天凌晨要从前一天新增的几百万条记录里随机抽5万条，进入样本库做后续分析。最早的实现就是一条ORDER BY RANDOM() LIMIT 50000，数据量小的时候每天跑几分钟，还能忍受。后来业务增长，前一天的记录涨到2000万条，这条SQL直接把数仓任务拖到了超时。后来改成主键区间偏移法，但主键因为存在删数逻辑，空洞率超过30%，抽出来的样本总量忽高忽低。最后是先用窗口函数把新增数据打成连续编号，存到一张中间表，再从中间表做随机偏移。那之后，每晚的任务从40多分钟降到了不到2分钟，稳如老狗。

那次事故给我的教训挺深的。其一，别迷信“标准写法”，ORDER BY RANDOM()语法简单、逻辑正确，但在工程上就是不可接受的；其二，优化的核心不是更快地做同一件事，而是换一种完全不同的方式达成目标。只要数据量上来了，任何全表排序都有优化空间；其三，也是最重要的，做抽样SQL之前先问一句“均匀性要求有多高”，能接受近似随机就用更快的方案，能提前预计算就别等到查询时现算。

最后再分享一个小技巧：无论你选了哪种方案，都建议把抽样SQL封装成一个独立的函数或存储过程，参数是抽样数量、过滤条件、随机种子。这样一方面可以统一管理，另一方面也方便后续替换实现，不影响业务方调用。抽样逻辑看起来简单，真正踩过坑的人才知道它有多少细节值得琢磨。