MySQL大表禁用ORDER BY RAND()，因其强制全表扫描和排序；替代方案为主键范围跳过或WHERE id>=FLOOR(RAND()*MAX(id))配合UNION ALL；PostgreSQL需ANALYZE保障RANDOM()准确；SQL Server可用NEWID()子查询优化；跨库复现抽样应固化随机种子。
直接用 ORDER BY RAND() LIMIT N 能抽，但只适用于几千行以内的表；超过 1 万行，性能会断崖式下跌，不是函数慢，是它强制全表扫描 + 全字段排序。
MySQL 大表千万别写 ORDER BY RAND()
执行 SELECT * FROM orders ORDER BY RAND() LIMIT 10 时，MySQL 会给每一行实时计算一个 RAND() 值，再把全部行按这个值排序——哪怕你只要 10 条，它也得扫完整个表、生成上百万个随机数、做一次大排序。磁盘临时表、内存爆满、查询超时都是常见后果。
替代方案优先考虑主键范围跳过：
- 先查
SELECT MIN(id), MAX(id) FROM orders得到范围 - 在应用层生成 20 个落在该范围内的随机整数（多取几个，防空）
- 再执行
SELECT * FROM orders WHERE id IN (123, 456, …)，去重后取满 10 条 - 如果必须纯 SQL，可用
WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM orders)) LIMIT 10，但主键不连续时大概率返回不足 10 条，需加UNION ALL备用逻辑
PostgreSQL 用 RANDOM() 更稳，但得配 ANALYZE
ORDER BY RANDOM() LIMIT 10 在 PostgreSQL 中行为可靠，每行独立调用，结果严格等概率。但它依赖查询规划器对总行数的估算——如果刚批量导入 100 万条数据却没运行 ANALYZE orders，规划器仍以为只有 10 万行，LIMIT 10 可能提前截断，实际只返回 3 条。
安全做法：
- 定期执行
ANALYZE orders（尤其在大批量 DML 后） - 若要近似但快得多，改用
TABLESAMPLE SYSTEM (1)，但注意：它按页抽样，含大字段（如TEXT）的页会被高估，样本分布不均 - 想精确又提速？建覆盖索引，例如只查
id, status，就建INDEX ON orders(id, status)，让ORDER BY RANDOM()走索引排序而非堆表扫描
SQL Server 的 NEWID() 不是万能解药
ORDER BY NEWID() 确实能逐行生成 GUID 实现真随机，但和 ORDER BY RAND() 一样，它也要把整张表所有行的 NEWID() 值算出来再排序。在 OLTP 环境中，这会吃光内存、拖慢并发查询。
更轻量的折中写法：
- 先用子查询限制中间集大小：
SELECT TOP 1000 id FROM orders ORDER BY NEWID() - 再用这些 ID 关联原表：
SELECT o.* FROM orders o JOIN (...) t ON o.id = t.id - 若表有自增
IDENTITY列，可用CHECKSUM(NEWID()) % 100 = 0做分桶，比全排序低一个数量级开销
跨库可复现抽样必须固化种子
审计、A/B 测试等场景下，RAND() 每次执行结果不同，无法回溯。MySQL 8.0+ 支持 RAND(42)，传固定整数种子就能复现同一随机序列；PostgreSQL 需先 SET SEED TO 0.42，再用 RANDOM()，但该设置仅对当前 session 生效。
最可控的方式其实是把随机逻辑移出 SQL：
- 用应用层生成哈希值，例如 Python 中
hashlib.md5(f"{row_id}_2026q3_audit".encode()).hexdigest()[:8] - 转成整数后取模：
int(hex_str[:6], 16) % 100 表示抽 5% - 这样逻辑可测试、可复现、不依赖数据库版本或 session 状态
真正麻烦的从来不是“怎么写出随机语句”，而是“怎么让随机结果既可控、又高效、还不偏态”——这三个目标往往互相冲突，得根据表结构、数据分布、QPS 要求一项项权衡。
