MySQL中ORDER BY RAND()在千万级表上会触发全表扫描和排序，导致严重性能问题；可行替代是主键范围随机采样或OFFSET+RANDOM()跳过法，PostgreSQL推荐TABLESAMPLE BERNOULLI/SYSTEM，SQL Server和SQLite宜用主键IN查询避开NEWID()/RANDOM()全表计算。
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 连续，否则会漏行或重复）
PostgreSQL 怎么安全地随机抽 5 行？
PostgreSQL 原生支持高效随机采样：TABLESAMPLE 是正解，它基于块级采样，不扫全表。
但要注意：默认的 SYSTEM 方法不是严格随机，而是按数据页抽样；如果要更均匀，改用 BERNOUILLI：
SELECT * FROM table TABLESAMPLE BERNOUILLI(0.01) LIMIT 5;
这里 0.01 是采样概率（1%），实际返回行数不固定，所以后面加 LIMIT 5。若怕抽不够，可略调高概率（比如 0.02）再 LIMIT 5。
-
BERNOUILLI对每行独立掷硬币，结果更随机，但小表可能抽不到足够行 -
SYSTEM更快，但局部聚集性强（比如连续几行来自同一数据页） - 两种方法都不依赖索引，也不要求主键连续
SQL Server 和 SQLite 怎么绕开 NEWID() 性能坑？
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 + limit 5”，比如 SELECT * FROM table LIMIT 5 OFFSET 123456，但问题在于：offset 越大，MySQL/PostgreSQL 仍要扫描前面所有行（哪怕不返回），性能随 offset 线性下降。
真正低开销的方式，永远依赖主键/索引字段的直接定位，而不是靠跳过。
- 主键必须是数字类型（
INT,BIGINT），字符串或 UUID 主键不适合此法 - 如果表没有主键，先加个自增列或用
ROW_NUMBER()（但窗口函数本身在大表上也重） - 线上环境别用
RAND()/NEWID()直接跑，先在测试库压测确认耗时
抽样这事，核心就一条：别让数据库做它不擅长的事——排序和全表打乱。用索引定位、块采样或预估范围，才是大表下的实际路径。主键是否连续、有没有索引、引擎类型，这些细节一换，方案就得跟着变。
