ORDER BY RAND() 极慢是因为需全表扫描并为每行计算随机数再排序，无法用索引；替代方案有主键范围采样法和添加rand_val字段+索引的预计算法。
ORDER BY RAND() 为什么慢得离谱
直接 ORDER BY RAND() LIMIT N 在百万级表上可能秒变“卡死现场”——MySQL 必须为每一行生成随机数、全表排序，再取前 N 条。I/O 和 CPU 双重压力，且无法用索引加速。
常见错误现象：SELECT * FROM user ORDER BY RAND() LIMIT 10 执行超 5 秒，EXPLAIN 显示 type: ALL（全表扫描）+ Extra: Using filesort。
- 数据量 > 10 万时，性能断崖式下降
- RAND() 是非确定性函数，会导致查询无法被 Query Cache 缓存（MySQL 5.7+ 已弃用，但原理仍影响执行计划）
- 在主从复制中，若 binlog_format = STATEMENT，
RAND()可能引发主从不一致（虽 MySQL 会自动转为 ROW，但旧环境需留意）
更靠谱的替代方案：采样法 + 主键范围预估
核心思路：避开全表排序，改用主键（或唯一递增字段）的数值分布做概率采样。前提是表有自增主键 id，且数据删除不频繁（空洞少）。
实操步骤：
- 先查出
MIN(id)和MAX(id)：SELECT MIN(id), MAX(id) FROM user - 在该范围内生成 N 个随机整数（例如 Python 的
random.sample(range(min_id, max_id + 1), N)） - 用
WHERE id IN (...)查询（注意：需去重 + 过滤掉已删除的 id，可能查不到足额 N 条） - 若结果不足 N 条，可补查一次（比如再生成 N 个新随机数），或改用
UNION ALL多次小范围LIMIT 1查询
示例 SQL（补查逻辑需业务层控制）：
SELECT * FROM user WHERE id IN (1024, 5678, 9999);
真正稳定的方案：加辅助随机字段 + 索引
如果需要高频、低延迟的随机抽样，建议提前建好“随机槽”。本质是把计算成本前置到写入/维护阶段。
操作方式：
- 给表加一列
rand_val（类型DOUBLE或INT），初始化填RAND()：UPDATE user SET rand_val = RAND() - 为该列建索引：
CREATE INDEX idx_rand ON user(rand_val) - 后续随机取 N 条：
SELECT * FROM user WHERE rand_val >= RAND() ORDER BY rand_val LIMIT N
注意点：
- 每次 INSERT 新记录时，必须同步设置
rand_val = RAND()；批量导入需额外处理 -
RAND()值重复概率极低，但ORDER BY rand_val仍可能返回略少于 N 条（因 >= 条件匹配数波动），可改为LIMIT N+5再在应用层截取 - 该方案对写入吞吐有轻微影响，但读取稳定在毫秒级，适合抽奖、推荐位轮播等场景
LIMIT 配合 OFFSET 的伪随机陷阱
有人用 SELECT * FROM user LIMIT N OFFSET FLOOR(RAND() * total_count) 模拟随机，看似避免了 ORDER BY RAND()，实则隐患更大。
问题根源：
-
total_count需提前COUNT(*)，本身是 O(n) 操作，高并发下易成瓶颈 - OFFSET 越大越慢（MySQL 仍要扫描跳过的行），当
OFFSET > 10 万，响应时间直线上升 - 若表有并发 DELETE，
OFFSET定位可能漏行或重复，无法保证“真正随机”
简单说：这不是随机抽取，只是“随机起点的顺序切片”，且代价不比 ORDER BY RAND() 小。
真正难的不是写出那条 SQL，而是想清楚“随机”的语义边界：要不要绝对均匀？能不能接受少量重复或空缺？是否允许写入开销换读取稳定？这些决策点，比函数名本身重要得多。
