ORDER BY RAND() 在大数据表上极慢，因需为每行生成随机数并全表排序；替代方案有主键范围采样（快但怕ID空洞）和LIMIT OFFSET分页（准但偏移大时慢）。
MySQL里用 ORDER BY RAND() 最简单，但数据量大时会严重拖慢查询速度，别无脑用。
为什么 ORDER BY RAND() 在大数据表上很危险
MySQL 执行 ORDER BY RAND() 时，会对**全表每行都生成一个随机数**，再排序、取前 N 条。这意味着：表有 100 万行，就要算 100 万次随机数 + 全排序 —— 磁盘 I/O 和 CPU 都扛不住，响应可能从毫秒级变成秒级甚至超时。
常见错误现象：SELECT * FROM users ORDER BY RAND() LIMIT 5 在百万级表上执行缓慢、占用高、可能触发慢查询告警。
适用场景：仅限小表（比如 SELECT 结果集稳定在几千行以内），或开发/测试环境临时取样。
- 不建议在生产环境的
user、order、log类大表中直接使用 - 如果表有主键且连续，可用主键范围采样替代
- MyISAM 引擎下
RAND()行为和 InnoDB 略有差异，但性能问题一致
更靠谱的替代方案：用主键范围 + WHERE 随机筛选
前提是表有自增主键（如 id），且数据删除不频繁（ID 分布相对均匀）。思路是：先估算主键最大值，生成几个随机 ID，再查这些 ID 对应的记录。
实操分两步：
- 查最大 ID：
SELECT MAX(id) FROM your_table - 用应用层（Python/PHP/Java）生成 N 个
[1, max_id]区间内的随机整数（去重） - 拼成查询：
SELECT * FROM your_table WHERE id IN (123, 456, 789)
注意点：
- 如果表存在大量删除，ID 空洞多，可能查不到足够记录，需加兜底逻辑（比如多生成 20% 随机数，或循环补查）
- 不能直接用
SELECT * FROM t WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) LIMIT 5—— 这种写法容易只返回连续几条，不满足“均匀随机”需求 - 该方法依赖主键索引，速度极快，基本恒定 O(N) 查询成本
需要真正均匀随机？考虑应用层分页 + 随机偏移
当业务要求严格随机（比如抽奖、A/B 测试抽样），且无法接受 ID 空洞偏差时，可结合表总行数与随机偏移做分页查询。
步骤：
- 先获取总行数：
SELECT COUNT(*) FROM your_table - 生成随机偏移：
offset = random_int(0, total_count - N) - 执行：
SELECT * FROM your_table LIMIT N OFFSET offset
风险提示：
-
COUNT(*)在大表上本身可能慢（尤其 InnoDB），可考虑用近似值（如information_schema.TABLES中的TABLE_ROWS） -
LIMIT … OFFSET越靠后越慢（MySQL 仍需扫描前面所有行），偏移量 > 10 万时性能明显下降 - 适合 N 小、total_count 不极大（比如百万内）、且能容忍少量误差的场景
真正难的是平衡“随机性质量”和“查询效率”。没有银弹 —— ORDER BY RAND() 简单但危险，主键采样快但怕空洞，OFFSET 分页准但怕偏移过大。选哪个，得看你表的实际大小、ID 分布、以及业务对“随机”的容忍度。
