在数据库日常开发中，从大表里随机抽取几条测试数据，看似是个小需求，但选错方法，后果可能比想象中严重得多。尤其当表规模达到千万级，一个简单的ORDER BY RAND()，往往会让数据库直接“罢工”——这不是危言耸听，而是真实线上经常踩的坑。
先说几个核心判断：ORDER BY RAND()在MySQL中会触发全表扫描和全排序，等于主动请数据库吃一顿全表扫描加全排序的家常便饭。PostgreSQL则有更好的原生方案，而SQL Server和SQLite各自也有更聪明的绕路方法，但前提是“选对方向”。
MySQL 中 ORDER BY RAND() 的代价与替代方案
千万级表上直接写 SELECT * FROM table ORDER BY RAND() LIMIT 5，基本等于主动触发全表扫描 + 全排序。MySQL需要给每一行算一个随机数、再排序、最后取前5——这期间磁盘IO和内存压力都会爆表，执行时间可能几十秒甚至直接超时。
真正可行的替代方案，是“采样跳过法”。核心思路很简单：先估算总行数，再用随机偏移避开排序，而不是让数据库去硬算。
- 先通过
SELECT COUNT(*) FROM table拿到总数。注意：如果表没有主键，或者用的是InnoDB引擎，COUNT(*)本身也可能慢，这时可以查information_schema.TABLES的TABLE_ROWS近似值，虽然精度不够高，但用于估算已经足够了。 - 在程序里生成5个不重复的随机整数，范围在0到总数-1之间。
- 对每个随机数
r，执行SELECT * FROM table LIMIT 1 OFFSET r。但这里有个前提：主键或自增ID必须连续，否则会漏行或重复。
这个方案比ORDER BY RAND()好得多，但需要保证主键连续性，并且最好在应用层做去重处理。
PostgreSQL 的“正规军”方案：TABLESAMPLE
PostgreSQL天生支持高效随机采样，这是它的一个优势。TABLESAMPLE是基于块级采样的，不会全表扫描，效果稳定。
但要注意细节：默认的SYSTEM方法不是严格随机，而是按数据页抽样。如果要更均匀的随机性，推荐改用BERNOUILLI：
SELECT * FROM table TABLESAMPLE BERNOUILLI(0.01) LIMIT 5;
这里0.01代表采样概率（1%），实际返回行数不固定，所以后面加个LIMIT 5兜底。如果担心抽不够，可以适当调高概率，比如0.02甚至更多。
两种方法的取舍很明确：
BERNOUILLI对每行独立掷硬币，结果更随机，但小表可能抽不到足够行。SYSTEM更快，但局部聚集性强，比如连续几行可能来自同一数据页。- 二者都不依赖索引，也不要求主键连续，这是它的核心优势。
SQL Server 和 SQLite：如何避开 NEWID() 和 RANDOM() 的性能坑？
SQL Server常见的写法是ORDER BY NEWID()，看似简单，但每行都要调用一次函数，大表上一样慢。SQLite的ORDER BY RANDOM()同理。
更稳的通用做法是“两步走”：先用主键范围生成随机ID，再用IN查询。前提是主键是数值型且分布相对均匀。
SELECT * FROM table WHERE id IN (12345, 67890, 23456, 78901, 34567);
具体步骤：
- 先查
SELECT MIN(id), MAX(id) FROM table，拿到主键范围。 - 在程序里生成5个
RAND() * (max - min) + min的整数。 - 用
WHERE id IN (...)查询，命中索引，毫秒级返回。 - 缺点：如果主键空洞太多（比如频繁删过大量数据），可能查不到5行，需要补抽。
为什么不能直接用 LIMIT + OFFSET 来随机跳？
很多人会想：“我随机取一个offset，比如SELECT * FROM table LIMIT 5 OFFSET 123456，不就行了吗？”
问题在于：offset越大，无论是MySQL还是PostgreSQL，仍然要扫描前面所有行（哪怕不返回），性能随offset线性下降。这就好比让数据库从头开始数，一直数到第123456行，效率极低。
真正低开销的方式，永远依赖主键/索引字段的直接定位，而不是靠跳过。
- 主键必须是数字类型（
INT、BIGINT），字符串或UUID主键不适合这个方案。 - 如果表没有主键，建议先加一个自增列，或者用
ROW_NUMBER()（但窗口函数在大表上本身也很重，属于无奈之举）。 - 线上环境千万别用
RAND()/NEWID()直接跑，务必先在测试库压测，确认耗时在可接受范围内。
抽样的核心原则只有一条：别让数据库做它不擅长的事——排序和全表打乱。用索引定位、块采样或预估范围，才是大表下的实际路径。主键是否连续、有没有索引、引擎类型，这些细节一换，具体方案就得跟着调整。
