ORDER BY RAND() 极慢是因为MySQL对每行调用RAND()并全量排序，导致IO和CPU双爆，10万行约2秒、100万行超30秒，且无法索引加速；替代方案是主键范围随机跳查或预生成ID表。
ORDER BY RAND() 为什么慢得离谱
因为 MySQL 对每行都调用一次 RAND()，再全量排序——数据量一过万，EXPLAIN 就会显示 Using filesort，IO 和 CPU 双爆。不是“有点慢”，是“数量级恶化”：10 万行可能 2 秒，100 万行可能 30 秒以上，且无法用索引加速。
常见错误现象：SELECT * FROM users ORDER BY RAND() LIMIT 10 在生产环境拖垮整个查询队列；监控里看到 Sort_merge_passes 暴涨；慢日志里反复出现同一句带 RAND() 的 SQL。
- 它不区分存储引擎——InnoDB 和 MyISAM 都一样慢
- 哪怕只
LIMIT 1，MySQL 仍要为全部 N 行生成随机数、排序、再取头 -
RAND()是非确定性函数，会导致查询无法被 Query Cache 缓存（如果还开着的话）
替代方案：用主键范围 + WHERE 随机跳查
核心思路是避开排序，转为“估算总数 → 生成随机 ID → 查找最近有效行”。前提是表有自增主键（或唯一递增字段），且无大量删除导致空洞。
实操步骤：
- 先执行
SELECT COUNT(*) FROM table_name得到总行数N - 在应用层生成一个随机整数
r，范围[1, N] - 执行
SELECT * FROM table_name WHERE id >= r ORDER BY id LIMIT 1
注意：这个方法抽样略有偏差（ID 空洞处概率略低），但对大多数运营、推荐、测试场景完全可接受。性能从秒级降到毫秒级，且能走主键索引。
更稳的方案：预生成随机 ID 表或用 UUID
当主键空洞严重（比如频繁删用户），上面的 WHERE id >= r 可能查不到数据，或返回结果偏少。这时要么补重试逻辑，要么换结构。
两种落地方式：
- 建一张
random_id_map表，定期用后台任务把所有有效id打乱后插入，每次抽样直接SELECT id FROM random_id_map ORDER BY RAND() LIMIT 10—— 这张表小（只有 ID 列），ORDER BY RAND()就不疼了 - 如果业务允许，把主键换成
UUID或ULID，再加一列seq_id BIGINT AUTO_INCREMENT作为稠密序号，抽样就回到上一节的安全路径
别硬扛：有些团队试图用 JOIN (SELECT FLOOR(RAND() * N) AS r) t ON t.r = table.id，但 RAND() 在 JOIN 条件里依然会被多次计算，没本质改善。
PostgreSQL 和 SQLite 怎么办
MySQL 的 ORDER BY RAND() 是典型反模式，但其他数据库处理逻辑不同，不能照搬优化。
- PostgreSQL 用
ORDER BY RANDOM()，同样慢；推荐用TABLESAMPLE SYSTEM (n)（如SELECT * FROM users TABLESAMPLE SYSTEM (1)抽约 1% 行），速度快、原生支持、无须改表结构 - SQLite 用
ORDER BY RANDOM()，小表没问题；大表建议先SELECT rowid FROM table ORDER BY RANDOM() LIMIT 10，再用这些rowid回查，避免全字段参与排序
跨数据库写通用代码时，千万别封装成 “db.random_select(10)” 这种黑盒——底层实现差异太大，容易在线上突然变慢。
真正麻烦的从来不是语法怎么写，而是你不知道哪次 RAND() 调用会卡住主库的复制线程。
