order by rand() 在大数据量下极慢，因需全表扫描并为每行计算随机数后排序，即使limit 1也无效；替代方案包括主键范围随机采样、时间窗口粗筛+rand()、uuid哈希分桶或预生成随机id池。
ORDER BY RAND() LIMIT N 在小表上能用，大表上会拖垮查询性能，甚至引发全表扫描和临时表爆炸。
为什么 ORDER BY RAND() 在大数据量下极慢
MySQL 执行 ORDER BY RAND() 时，必须为表中每一行计算一个随机数，然后对整个结果集排序——哪怕你只想要 1 条。这意味着：
- 全表扫描不可避免，即使有索引也基本失效
- 需要额外内存构建临时表存放
RAND()值 + 原始行数据 - 当表有百万级行时，
SELECT * FROM t ORDER BY RAND() LIMIT 10可能耗时数秒甚至超时 - 并发稍高时，CPU 和内存压力陡增，影响其他查询
替代方案：用主键范围随机 + LIMIT 1 多次（适用于主键连续或较密集）
避开排序，改用主键做概率采样。假设表 t 主键是 id（INT，自增，无大量删除空洞）：
SELECT * FROM t WHERE id >= FLOOR(1 + RAND() * (SELECT MAX(id) FROM t)) LIMIT 1;
但单次只能取 1 条；要取 N 条，需执行 N 次（应用层控制），或用 UNION ALL 合并（N 不宜 > 5，否则 SQL 过长且可能重复）：
(SELECT * FROM t WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) LIMIT 1) UNION ALL (SELECT * FROM t WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) LIMIT 1) -- 重复 N 次，注意去重逻辑需应用层补足
⚠️ 注意：FLOOR(RAND() * MAX(id)) 可能生成不存在的 id（如被删过），导致结果少于 N 条，需兜底重试或改用 JOIN 补齐。
更稳的方案：用 UUID 或时间戳辅助抽样（适合有辅助字段的场景）
如果表里有 created_at 或已存 uuid 字段，可绕过主键依赖：
- 用
WHERE created_at >= DATE_SUB(NOW(), INTERVAL FLOOR(RAND() * 30) DAY)先粗筛时间窗口，再ORDER BY RAND() LIMIT N—— 数据量大幅减少后，RAND()开销可控 - 若每行有
uuid字段（非主键），可用WHERE uuid REGEXP '^[\da-f]{2}'类似哈希分桶（例如取前两位十六进制值匹配某范围），再 LIMIT，实现近似均匀采样 - 不推荐
MD5(id)等计算字段做 WHERE 条件——无法走索引，仍会全表计算
真正生产可用的折中：预生成随机ID池 + 应用层缓存
对实时性要求不高、且 N 固定（如首页推荐 6 条）的场景，最实用的是离线维护：
- 每天凌晨用存储过程生成一次随机 ID 列表，写入一张
random_pool表（字段：pool_name,item_id,seq） - 应用查
SELECT item_id FROM random_pool WHERE pool_name = 'homepage' ORDER BY seq LIMIT 6—— 索引直取，毫秒级 - 避免每次请求都触发
RAND()，也规避了事务中不可重复读导致的“抽到同一条两次”问题
真正难处理的不是语法怎么写，而是没想清楚：你要的“随机”，是会话级唯一、事务级一致，还是只要肉眼看起来差不多就行？后者往往用偏移+固定种子 ORDER BY id * 1000 + 12345 都比 RAND() 更靠谱。
