ORDER BY RAND() 会导致全表扫描、文件排序和临时表三连击，应改用主键范围查询、应用层随机或JOIN偏移法等优化方案。
别用 ORDER BY RAND() 查大表，它不是慢，是根本没走索引——全表扫描 + 文件排序（Using filesort）+ 临时表（Using temporary）三连击，100 万行起步就卡死。
为什么 ORDER BY RAND() 一定触发全表扫描
MySQL 5.7 的优化器无法为 RAND() 构建有序路径：B+ 树索引依赖值的确定性顺序，而每行调用一次 RAND() 得到的值完全不可预测。优化器直接放弃索引，转而执行「全表读取 → 每行算一个随机数 → 写入临时表 → 全局排序 → 取 LIMIT」。哪怕只查 1 行，也得扫完整张表。
常见错误现象：
-
EXPLAIN显示type: ALL、Extra: Using temporary; Using filesort - 50 万行表查 10 条随机数据，耗时从 20ms 跳到 8s
- 并发稍高，
max_execution_time被触发或连接被 kill
用主键范围 WHERE 替代，必须加 MIN(id) 偏移
前提：表有自增/有序整型主键（如 id），且空洞率不高（删过少量记录可接受）。核心是绕过排序，靠主键索引直接定位。
错误写法（漏掉最小值偏移）：WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t))
→ 会集中在开头几行重复命中，随机性崩坏。
正确写法（带偏移）：WHERE id >= FLOOR(RAND() * ((SELECT MAX(id) FROM t) - (SELECT MIN(id) FROM t)) + (SELECT MIN(id) FROM t)) ORDER BY id LIMIT 1
这个语句能走 PRIMARY KEY 索引，EXPLAIN 显示 type: range，百万级表稳定在 0.01–0.03 秒。
注意点：
- 如果
id空洞严重（比如删了 30% 中间记录），可能返回空结果 —— 这不是 bug，是设计取舍，需应用层兜底重试 - 单次只能取 1 行；要取 N 行，得循环 N 次（或 JOIN 多次），但总耗时仍是 O(N) 级别，远优于 O(n log n)
应用层随机 + 回表查询，适合 ID 总量可控的场景
当主键空洞多、或表无合适整型主键时，更稳妥的方式是把随机逻辑提到应用层。
操作步骤：
- 先查一遍所有 ID：
SELECT id FROM t（可缓存，比如 Redis 存 5 分钟） - 应用层用
shuffle或random.sample随机选 N 个 ID - 用
WHERE id IN (?, ?, ?)回表查完整字段
优势：随机性最真实，性能稳定（扫描行数 ≈ 总 ID 数 + N）；劣势：ID 列表内存占用与总量成正比，不适用于千万级 ID 场景。
容易踩的坑：
- 忽略缓存失效策略，导致数据陈旧或频繁穿透 DB
- 未限制 ID 列表最大长度（比如超 10 万就切分或降级）
- IN 参数超过 MySQL 默认
max_allowed_packet，需拆批
JOIN 偏移法：平衡随机性与空洞容忍度
比纯主键范围法更鲁棒，适合空洞率中等（
典型写法：SELECT * FROM t AS t1 JOIN (SELECT ROUND(RAND() * ((SELECT MAX(id) FROM t) - (SELECT MIN(id) FROM t)) + (SELECT MIN(id) FROM t)) AS random_id) AS t2 ON t1.id >= t2.random_id ORDER BY t1.id LIMIT 1
原理：生成一个基准 ID，找第一个 ≥ 它的记录，利用索引快速跳转。
关键细节：
- 必须用
ROUND或FLOOR，不能直接用浮点数参与比较 - JOIN 子查询里不能省略
MIN(id)，否则基准始终从 0 开始 - 仍可能因空洞返回空，建议外层加
IFNULL或应用层 fallback
真正难处理的不是语法怎么写，而是空洞率和随机质量之间的权衡：主键范围法快但怕空洞，应用层法准但吃内存，JOIN 法折中但 SQL 更复杂。上线前务必用真实数据分布压测，别只看 EXPLAIN 的 type 字段。
