ORDER BY RAND() 慢得离谱是因为 MySQL 需对每一行重复计算 RAND() 并全量排序，即使 LIMIT 1 也触发全表扫描、临时表和 filesort，导致 I/O 与 CPU 双爆；小数据量（
ORDER BY RAND() 在 MySQL 中为什么慢得离谱
RAND() 每次被调用都会为结果集中的每一行重新计算一个随机浮点数，MySQL 必须先生成完整临时表、给每行打上随机值、再全量排序——哪怕你只 LIMIT 1。数据量一过万行，执行计划里就大概率出现 Using temporary; Using filesort，I/O 和 CPU 双爆。
实操建议：
- 小数据量（SELECT * FROM users ORDER BY RAND() LIMIT 10
- 中等数据量（5000–10w）改用「主键随机跳查」：先
SELECT MIN(id), MAX(id) FROM users，在应用层生成 N 个随机id，再SELECT * FROM users WHERE id IN (…)（注意去重和不存在 id 的兜底） - 大数据量或高并发场景，别碰
ORDER BY RAND()，它本质是反索引、反缓存的设计
NEWID() 是 SQL Server 的“真随机”，但代价不低
NEWID() 每次返回一个新生成的 GUID，SQL Server 会为每行调用一次，同样触发全表扫描 + 全内存排序。它比 RAND() 更“随机”（无种子、不可复现），但性能更差，且无法利用任何索引。
常见错误现象：
- 在视图或函数里用了
ORDER BY NEWID()，导致每次查询都不可缓存，执行计划反复编译 - 配合
TOP N时仍扫描全表，不是“取到 N 行就停”
替代方案：
- 用
TABLESAMPLE SYSTEM (5)（近似随机抽样，快但不精确，不保证行数） - 建一个带
AS (ABS(CHECKSUM(NEWID())) % 100)的计算列并索引，查WHERE random_bucket = 0实现分桶随机 - 如果只是想打乱展示顺序，前端取全量后
shuffle()更省数据库资源
跨数据库的轻量级随机采样思路
没有银弹，但可以绕开 ORDER BY … RANDOM() 这条路：
- PostgreSQL 用
TABLESAMPLE BERNOULLI (1)或ORDER BY RANDOM() LIMIT N（比 MySQL 的RAND()略优，因优化器能更好估算） - SQLite 支持
ORDER BY RANDOM() LIMIT N，小表可用；大表建议先SELECT rowid FROM tbl ORDER BY RANDOM() LIMIT N，再连表查详情 - 所有数据库都适用的底线方案：加一个
is_sampled BOOLEAN DEFAULT FALSE字段，用后台任务定期随机设为TRUE（比如每天跑一次UPDATE tbl SET is_sampled = TRUE WHERE id IN (SELECT id FROM tbl ORDER BY RANDOM() LIMIT 1000)），查询走索引
为什么不能用 LIMIT 和 OFFSET 配合随机偏移
有人试过：SELECT * FROM users LIMIT 10 OFFSET FLOOR(RAND() * (SELECT COUNT(*) FROM users)) —— 看似避开排序，实际更危险。
问题在于：
-
COUNT(*)本身就要全表扫，再加一次LIMIT/OFFSET查询，等于扫两次表 - 并发请求下，
COUNT(*)结果可能变化，OFFSET 越界直接返回空 - OFFSET 越大越慢（MySQL 必须跳过前面所有行），随机 offset 基本等于随机慢查询
真正要稳，就得接受「随机 ≠ 每次都从全集均匀抽」，而是用预计算、分桶、或应用层协同的方式把不确定性卸载出去。
