<p>ORDER BY RAND()在MySQL 5.7中必然全表扫描，因其为行级非确定性函数，无法利用B+树索引；应改用id >= FLOOR(RAND() * MAX(id))等索引友好方案或应用层预取ID洗牌。</p>
为什么ORDER BY RAND()在MySQL 5.7里必然全表扫描
因为RAND()是行级非确定性函数，优化器无法为它建立索引访问路径——B+树依赖值的有序性，而每行的RAND()结果完全独立、不可预测。执行EXPLAIN一定看到type: ALL和Extra: Using temporary; Using filesort。哪怕表只有10万行，I/O和CPU开销也会陡增；100万行以上，查询常卡死或触发超时。
用WHERE id >= FLOOR(RAND() * MAX(id))替代（最常用）
前提是主键为自增整型且空洞不严重（比如删过不到10%数据）。它把O(n log n)排序降为O(log n)索引查找。
- 必须提前查出
MAX(id)并缓存（如Redis），避免子查询重复执行：直接写(SELECT MAX(id) FROM t)会让该子查询在每行都重算 - WHERE条件要加
id >=而非id =，否则空洞导致查不到数据；配合ORDER BY id LIMIT N能取到最近的有效行 - 若业务要求严格均匀，需在应用层补重试逻辑（最多2–3次），或叠加
MIN(id)做偏移校准：WHERE id >= FLOOR(RAND() * (MAX(id) - MIN(id))) + MIN(id) - 外层有WHERE过滤（如
status = 1）时，子查询里的WHERE必须完全一致，否则范围错位，抽样偏差放大
主键稀疏或UUID时改用应用层ID预取
当id不是数字、或删除频繁导致大量空洞（比如用户表高频注销），上面的范围跳查会频繁失败。此时应放弃SQL内随机，改由应用层控制。
- 第一步：用
SELECT id FROM t WHERE ...一次性取出所有符合条件的ID（可加缓存，TTL设为几分钟） - 第二步：在应用中用
random.shuffle()或Fisher-Yates洗牌，取前N个 - 第三步：用
WHERE id IN (?,?,?)回查完整字段——IN列表长度建议≤1000，超量则分批 - 注意：别在SQL里拼接长字符串ID列表，易触发max_allowed_packet或注入风险；始终用参数化查询
别碰JOIN模拟随机或GROUP_CONCAT采样
这类写法看似“没用ORDER BY RAND()”，但实际更危险：
-
JOIN (SELECT ROUND(RAND() * MAX(id)) AS r FROM t) AS t2 ON t1.id = t2.r：JOIN条件中的RAND()仍被多次求值，执行计划仍是全表扫描 -
GROUP_CONCAT(id)再FIND_IN_SET：字符串拼接上限受group_concat_max_len限制，默认仅1024字节，大数据量直接截断，结果不全 -
LIMIT FLOOR(RAND() * N), 1：需要先COUNT(*)，但COUNT本身在大表上就慢；且并发高时，COUNT结果可能已过期，导致OFFSET越界
真正难的不是选哪种方案，而是识别你的主键是否“够稠密”、WHERE条件是否“可下推”、以及能否接受轻微抽样偏差——这些细节不验证，再漂亮的SQL也救不了性能。
