ORDER BY RAND() 必然全表扫描且索引失效，因RAND()不可预测导致优化器无法利用B+树有序性；应改用主键范围查询、应用层ID洗牌或随机池表等替代方案。
MySQL 中 ORDER BY RAND() 必然触发全表扫描 + filesort，索引完全失效——这不是写法或配置问题，而是 RAND() 的不确定性导致优化器无法构建有序访问路径。任何指望“加个索引就能加速”的尝试都会失败。
为什么 ORDER BY RAND() 一定走不了索引
因为 RAND() 每行调用一次、结果不可预测，B+树索引依赖列值的确定性与有序性，而随机数既不有序也不可复现。优化器看到 ORDER BY RAND() 就直接放弃索引路径，改走 type: ALL + Using temporary; Using filesort。哪怕你只 LIMIT 1，它也得为全部百万行生成随机数、排序、再截取——IO 和 CPU 双爆表。
用主键范围查询替代（最常用且高效）
前提是主键为数字型、自增、空洞不严重（如 ID 删除不多）。核心是绕过排序，改用「估算范围 → 随机偏移 → 索引查找」：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
SELECT * 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 10;-
FLOOR()比ROUND()更安全，避免越界；显式加上MIN(id)偏移，否则随机起点从 0 开始，大量命中开头几行 - 若返回行数不足（因 ID 空洞），需在应用层补查：最多重试 2–3 次，每次生成新随机起点
-
MAX(id)和MIN(id)是轻量查询，建议缓存（如 Redis，TTL 设为 60 秒），避免每次执行都查两次
主键稀疏或非数字时的备选方案
当主键是 UUID、或删过大量数据导致严重空洞（比如 MAX(id) = 1000000 但实际只剩 5 万行），上面的范围法会频繁查不到数据。这时可用：
- 应用层预取 ID 列表：
SELECT id FROM t;缓存后，在代码里用Collections.shuffle()或random.sample()打乱，再WHERE id IN (...)回表——随机性最好，但内存占用随总行数线性增长，适合 ≤10 万行 - JOIN 随机起点（慎用）：
SELECT t1.* FROM t AS t1 JOIN (SELECT CEIL(RAND() * (SELECT MAX(id) FROM t)) AS id) AS t2 ON t1.id >= t2.id ORDER BY t1.id LIMIT 10;——比ORDER BY RAND()快一个数量级，但子查询里的RAND()在某些 MySQL 版本中可能被多次求值，建议拆成两步执行 - 维护一张「随机池表」：定时（如每小时）用后台任务把
id随机打乱后写入一张小表，查询时直接LIMIT读取——适合高并发、强一致性要求场景，但引入额外运维成本
真正容易被忽略的是：所有替代方案都默认牺牲了「严格均匀随机」。比如范围法偏向大 ID 区间（因空洞导致密度低），JOIN 法有概率漏掉末尾记录。如果业务真要求统计学意义上的均匀分布（例如抽奖系统），必须接受应用层洗牌 + 全量 ID 加载，或引入外部随机服务——数据库原生命令层面没有银弹。
