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