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 各方案选型对比参考很多朋友问过我这么多方案到底该选哪个我把主要方案的适用场景和性能特征整理成了一张表方便各位对照选择。方案适用数据量均匀性查询性能实现复杂度典型场景ORDER BY RANDOM()万级以内高低极低小表临时抽样TABLESAMPLE SYSTEM千万级以上低极高极低快速探查大表TABLESAMPLE BERNOULLI百万级以上中中高低一般抽样统计主键区间偏移法百万至千万级高主键连续时极高低自增主键表随机抽随机排序列预计算千万级以上中极高中用户端高频随机展示分桶抽样亿级以上中低高中高分区表大规模抽样选型的总体思路是先看数据量再看均匀性要求最后看实现成本。绝大多数场景主键区间偏移法和预计算随机列已经够用了只有到亿级数据才需要考虑分桶抽样这类更复杂的策略。6. 从一次线上事故聊到的一点体会几年前我接手过一个统计报表系统每天凌晨要从前一天新增的几百万条记录里随机抽5万条进入样本库做后续分析。最早的实现就是一条ORDER BY RANDOM() LIMIT 50000数据量小的时候每天跑几分钟还能忍受。后来业务增长前一天的记录涨到2000万条这条SQL直接把数仓任务拖到了超时。后来改成主键区间偏移法但主键因为存在删数逻辑空洞率超过30%抽出来的样本总量忽高忽低。最后是先用窗口函数把新增数据打成连续编号存到一张中间表再从中间表做随机偏移。那之后每晚的任务从40多分钟降到了不到2分钟稳如老狗。那次事故给我的教训挺深的。其一别迷信“标准写法”ORDER BY RANDOM()语法简单、逻辑正确但在工程上就是不可接受的其二优化的核心不是更快地做同一件事而是换一种完全不同的方式达成目标。只要数据量上来了任何全表排序都有优化空间其三也是最重要的做抽样SQL之前先问一句“均匀性要求有多高”能接受近似随机就用更快的方案能提前预计算就别等到查询时现算。最后再分享一个小技巧无论你选了哪种方案都建议把抽样SQL封装成一个独立的函数或存储过程参数是抽样数量、过滤条件、随机种子。这样一方面可以统一管理另一方面也方便后续替换实现不影响业务方调用。抽样逻辑看起来简单真正踩过坑的人才知道它有多少细节值得琢磨。 
长河君 · 2026/10/15 20:14:24 · 阅读 1.2k 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 各方案选型对比参考很多朋友问过我这么多方案到底该选哪个我把主要方案的适用场景和性能特征整理成了一张表方便各位对照选择。方案适用数据量均匀性查询性能实现复杂度典型场景ORDER BY RANDOM()万级以内高低极低小表临时抽样TABLESAMPLE SYSTEM千万级以上低极高极低快速探查大表TABLESAMPLE BERNOULLI百万级以上中中高低一般抽样统计主键区间偏移法百万至千万级高主键连续时极高低自增主键表随机抽随机排序列预计算千万级以上中极高中用户端高频随机展示分桶抽样亿级以上中低高中高分区表大规模抽样选型的总体思路是先看数据量再看均匀性要求最后看实现成本。绝大多数场景主键区间偏移法和预计算随机列已经够用了只有到亿级数据才需要考虑分桶抽样这类更复杂的策略。6. 从一次线上事故聊到的一点体会几年前我接手过一个统计报表系统每天凌晨要从前一天新增的几百万条记录里随机抽5万条进入样本库做后续分析。最早的实现就是一条ORDER BY RANDOM() LIMIT 50000数据量小的时候每天跑几分钟还能忍受。后来业务增长前一天的记录涨到2000万条这条SQL直接把数仓任务拖到了超时。后来改成主键区间偏移法但主键因为存在删数逻辑空洞率超过30%抽出来的样本总量忽高忽低。最后是先用窗口函数把新增数据打成连续编号存到一张中间表再从中间表做随机偏移。那之后每晚的任务从40多分钟降到了不到2分钟稳如老狗。那次事故给我的教训挺深的。其一别迷信“标准写法”ORDER BY RANDOM()语法简单、逻辑正确但在工程上就是不可接受的其二优化的核心不是更快地做同一件事而是换一种完全不同的方式达成目标。只要数据量上来了任何全表排序都有优化空间其三也是最重要的做抽样SQL之前先问一句“均匀性要求有多高”能接受近似随机就用更快的方案能提前预计算就别等到查询时现算。最后再分享一个小技巧无论你选了哪种方案都建议把抽样SQL封装成一个独立的函数或存储过程参数是抽样数量、过滤条件、随机种子。这样一方面可以统一管理另一方面也方便后续替换实现不影响业务方调用。抽样逻辑看起来简单真正踩过坑的人才知道它有多少细节值得琢磨。