order by rand()必须全表扫描，因mysql需对where筛选后的每行调用rand()生成随机值，再全量filesort取limit；索引完全失效，explain显示type: all和using temporary; using filesort。
ORDER BY RAND() 为什么必须全表扫描
MySQL 在执行 ORDER BY RAND() 时，不会先过滤、再随机，而是**对 WHERE 条件筛选后的每一行都调用一次 RAND() 函数**，然后把所有结果加载进临时内存（或磁盘）做 filesort。哪怕你只写 LIMIT 1，它也得为全部 N 行生成随机数、排序、再取头——索引完全失效。EXPLAIN 一定显示 type: ALL 和 Extra: Using temporary; Using filesort。
为什么加了主键索引也没用
RAND() 是非确定性函数，MySQL 无法预判其输出值，因此无法利用任何索引加速排序过程。主键索引在 ORDER BY RAND() 场景下形同虚设，不是“没配好”，是执行模型决定的必然结果。InnoDB 和 MyISAM 表表现一致，不存在引擎级优化空间。
并发一高就雪崩的真实原因
每个 ORDER BY RAND() 查询都会争抢以下资源：
-
sort_buffer_size内存：每并发 10 个查询，可能吃掉几百 MB 内存 - CPU：百万行 = 百万个
RAND()调用 + 快排计算 - 磁盘 I/O：当
filesort溢出到临时文件，触发大量随机读写 - 连接池：JDBC 若未设
queryTimeout，一条慢查询就能卡死一个连接
阿里监控曾记录：单条 ORDER BY RAND() 在促销期引发 Sort_merge_passes 指标飙升 20 倍，直接拖垮整个数据库实例。
你以为的“小优化”其实更糟
这些写法看似聪明，实则加剧问题：
-
WHERE id IN (SELECT id FROM t ORDER BY RAND() LIMIT 10)：子查询仍全表排序 -
RAND() * MAX(id)放在 WHERE 里：子查询被每行重复执行，效率反降 -
GROUP_CONCAT(id)+FIND_IN_SET：字符串拼接有长度上限，易内存溢出 - 硬拼
"LIMIT " + n：把性能炸弹直接注入 SQL 字符串
真正关键的分水岭不在“怎么写 SQL”，而在于“要不要让数据库承担随机逻辑”——绝大多数场景，答案是否定的。
