ORDER BY RAND() 必然导致索引失效，因其每行随机计算、无序可索引，优化器强制全表扫描并 filesort；替代方案包括主键范围抽样、OFFSET+LIMIT 随机偏移或维护随机池表。
MySQL 5.7 对 ORDER BY RAND() 基本不走索引，这不是配置或写法问题，而是设计使然 —— 它天然触发全表扫描 + filesort。
为什么 ORDER BY RAND() 必然导致索引失效
MySQL 5.7 的优化器无法为 RAND() 生成确定性排序路径：B+树索引依赖列值的有序性，而 RAND() 每行计算一次、结果完全随机，索引无法预建“随机序”。所以优化器直接放弃索引，改用临时表 + filesort 排序，再取前 N 行。
- 执行
EXPLAIN会看到type: ALL、Extra: Using temporary; Using filesort - 即使你在
id上有主键或自增索引，ORDER BY RAND()也完全无视它 - 表越大，性能断崖式下跌 —— 10 万行可能秒级，100 万行就卡顿明显
用主键范围抽样替代全表 RAND()
核心思路：避开排序，改用「估算主键范围 + 随机 ID 查询」，把 O(n log n) 降为 O(1) 单次回表（或 O(k) 少量回表）。
- 先查表的主键最小值和最大值：
SELECT MIN(id), MAX(id) FROM t - 在该范围内生成 K 个随机整数（比如用应用层
random.randint(min_id, max_id)） - 用
WHERE id IN (…)或多次WHERE id = ?查询 —— 这些都能命中主键索引 - 若存在 ID 空洞（删过数据），可多生成 20%~50% 的随机 ID，再去重、补足数量
示例（伪代码）：
SELECT * FROM t WHERE id IN (12345, 67890, 24680);
注意：此法要求主键是数字型且相对稠密；若主键是 UUID 或严重稀疏，需换用其他策略（见下一条）。
用 OFFSET + LIMIT 配合随机偏移（适用于中等数据量）
对主键连续、无大空洞的表，可用「估算总行数 → 随机 offset → 取一行」方式，避免排序开销。
- 先获取近似行数：
SELECT COUNT(*) FROM t（或查information_schema.TABLES的TABLE_ROWS，误差可接受） - 生成随机 offset：
offset = FLOOR(RAND() * (total - 1)) - 执行：
SELECT * FROM t ORDER BY id LIMIT 1 OFFSET ?—— 此时ORDER BY id可走主键索引，LIMIT 1让优化器用索引快速跳转
缺点：多次执行需多次 OFFSET，且 OFFSET 越大，扫描成本越高（虽比 RAND() 好，但非最优）；不适合要取 10+ 行的场景。
真正稳定高效的做法：维护一张「随机池表」
如果业务频繁需要随机样本（如首页推荐、抽奖池），别每次实时算 —— 提前把候选 ID 打散存入一张轻量表，定期刷新。
- 建表：
CREATE TABLE t_random_pool (id BIGINT PRIMARY KEY, rand_val DOUBLE) - 每天凌晨用
INSERT INTO t_random_pool SELECT id, RAND() FROM t全量刷新（离线做） - 查随机 N 条：
SELECT t.* FROM t JOIN t_random_pool p ON t.id = p.id ORDER BY p.rand_val LIMIT N
关键点：t_random_pool 很小（只有 ID + double），ORDER BY p.rand_val 在内存中完成，且 p.rand_val 可加索引（MySQL 8.0+ 支持函数索引，5.7 可用生成列模拟）；主表 t 仍走主键关联，全程无全表扫描。
这个方案把“随机性”和“查询性能”解耦 —— 随机性在写入时保证，读取时只做高效关联。线上高并发随机取数场景中，这是 MySQL 5.7 下最可控的选择。
