ORDER BY RAND()慢是因为需为每行生成随机数并全表排序，再取LIMIT结果；推荐用主键范围随机抽样（如WHERE id >= CEIL(RAND() * MAX(id)) ORDER BY id LIMIT N）替代。
MySQL用ORDER BY RAND()取随机记录为什么慢
因为ORDER BY RAND()会为表中**每一行**生成一个随机数，再对全量结果排序，最后才截取前5条。哪怕只想要5条，也要扫描、计算、排序全部数据——100万行的表，代价就是100万次随机数生成+全排序。
常见错误现象：SELECT * FROM users ORDER BY RAND() LIMIT 5 在大表上执行超时或拖垮数据库。
- 数据量
- 有主键且连续（或近似连续）：优先考虑基于主键的随机ID采样
- 表有高频写入：
RAND()可能引发排序缓冲区争用，加剧延迟
用主键范围随机采样替代ORDER BY RAND()
原理是避开排序，直接构造随机ID去查。前提是主键是自增整型且分布相对均匀（无大量删除导致空洞）。
实操步骤：
- 先查出主键最小值和最大值：
SELECT MIN(id), MAX(id) FROM users - 在应用层生成 N 个落在该范围内的随机整数（比如5个）
- 用
WHERE id IN (...)查询，注意需去重并补足数量（因随机ID可能不存在）
示例（Python片段）：
JOIN
- 这个写法仍可能因ID空洞返回空结果，需加
IFNULL或重试逻辑 - 执行5次该语句性能未必优于一次
ORDER BY RAND() LIMIT 5，尤其网络往返开销高时 - MySQL 8.0+ 可用
ROW_NUMBER() OVER(ORDER BY RAND())，但依然触发全表随机排序，未解决根本问题
真正适合线上环境的折中方案：预生成随机池
如果业务允许“近实时随机”（比如每小时更新一次），就不要每次请求都算——建一张random_pool表，定时任务把最新50–100条候选记录打乱后写入，查询时直接LIMIT 5。
- 写入频率低：用
INSERT INTO random_pool SELECT * FROM users ORDER BY RAND() LIMIT 100每小时跑一次 - 读完全无压力：
SELECT * FROM random_pool ORDER BY RAND() LIMIT 5只在100行内排序 - 关键点：池子要定期刷新，且需处理新老数据混合问题（比如加
updated_at字段过滤过期记录）
这个方案把随机计算从“每次请求”下沉到“固定周期”，是多数高并发场景下最可控的选择。
实际中最容易被忽略的是ID空洞对采样成功率的影响，以及没意识到ORDER BY RAND()在执行计划里显示为“Using temporary; Using filesort”——这俩提示已经说明它正在干一件很重的事。
