ORDER BY RAND()性能差是因为需全表扫描、逐行调用RAND()生成随机值、全量文件排序，索引失效，导致I/O和CPU双爆；改用主键范围WHERE查询可降至0.01–0.03秒。
RAND() 是可行的，但直接用 ORDER BY RAND() LIMIT N 在大表上会严重拖慢查询，尤其当表有几十万行以上时。
为什么 ORDER BY RAND() 性能差？
MySQL 必须为表中每一行都调用一次 RAND()，生成临时随机值，再对整张临时结果排序，最后取前 N 条。即使你只要 1 条，它也得扫全表、算全表、排全表。
- 没有索引可加速，
RAND()是非确定性函数，无法被优化器下推或剪枝 - 临时表可能落盘（
Using temporary; Using filesort），I/O 开销陡增 - 并发高时，大量临时排序会争抢 sort_buffer 和磁盘临时空间
小表（
如果表确实很小，且查询频次不高，ORDER BY RAND() 最简明可靠：
SELECT * FROM users ORDER BY RAND() LIMIT 5;
- 确保
users表行数稳定在万级以内，可通过SELECT COUNT(*) FROM users验证 - 避免在事务中频繁执行——
RAND()在同一事务内多次调用可能返回相同值（取决于 MySQL 版本和隔离级别） - 不要在 WHERE 条件里嵌套
RAND()，比如WHERE RAND() ，这会导致非均匀采样且仍需全表扫描
大表怎么高效随机取 N 条？
核心思路是「避开排序」：先估算主键范围，用随机数跳到近似位置，再用主键范围查询兜底。
- 假设主键
id是自增且无大片空洞，执行：SELECT * FROM users WHERE id >= FLOOR(1 + RAND() * (SELECT MAX(id) FROM users)) LIMIT 5;
- 为提高命中率，可多取一点再截断：
SELECT * FROM users WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM users)) ORDER BY id LIMIT 100; -- 取 100 行再应用业务逻辑筛选
- 若主键有空洞或不连续，更稳妥的方式是用两个随机偏移 + UNION：
(SELECT * FROM users LIMIT 1 OFFSET FLOOR(RAND() * (SELECT COUNT(*) FROM users))) UNION ALL (SELECT * FROM users LIMIT 1 OFFSET FLOOR(RAND() * (SELECT COUNT(*) FROM users))) LIMIT 5;
注意：OFFSET 本身也有性能成本，仅适用于 COUNT 结果缓存可用的场景
真正要注意的细节
很多人以为加了 LIMIT 就万事大吉，其实 RAND() 的行为在不同上下文里差异很大：
-
SELECT RAND(), RAND()同一行返回两个不同值；但SELECT RAND() AS r, r中第二个r是别名复用，值相同 - 子查询里用
RAND()可能被优化器物化，导致“伪随机”——例如(SELECT RAND() FROM dual) AS r在外层多次引用时可能不变 - 从 MySQL 8.0.17 起，
RAND()在窗口函数中禁止使用，会报错ERROR 3579 (HY000): RAND() not allowed in window function
最稳的办法永远是：先评估数据量，再决定用简单方案还是绕开 RAND() 的工程方案。别让“随机”成为慢查询的隐形推手。
