order by rand() 在大数据量下变慢是因为需全表扫描、为每行计算随机数并文件排序，索引失效；改用主键范围随机查询可大幅提升性能，explain 显示 type: range，耗时稳定在 0.01–0.03 秒。
为什么 ORDER BY RAND() 在大数据量下会变慢
因为 MySQL 必须为每一行调用 RAND() 函数，再对全部结果做文件排序（filesort），最后才取 LIMIT。哪怕你只要 1 条，它也得扫描全表、生成上百万个随机数、排序上百万行——索引完全失效，IO 和 CPU 双爆表。
典型表现是：10 万行表查 5 条随机数据，耗时从几毫秒跳到 1.2 秒；100 万行时可能超 5 秒甚至被 kill。EXPLAIN 会显示 type: ALL 和 Extra: Using filesort。
用主键范围 + WHERE 替代 ORDER BY RAND()
前提是表有自增/有序主键（id），且空洞不严重（比如没频繁物理删除）。核心思路：在 [MIN(id), MAX(id)] 范围内生成一个随机起点，向后取第 1 条。
直接可用的语句：
SELECT * FROM `table` WHERE id >= FLOOR(RAND() * ((SELECT MAX(id) FROM `table`) - (SELECT MIN(id) FROM `table`)) + (SELECT MIN(id) FROM `table`)) ORDER BY id LIMIT 1;
关键点：
-
FLOOR()比ROUND()更稳妥，避免越界； - 必须显式写
MIN(id)偏移，否则随机数从 0 开始，大量命中开头几行； - 如果
id有空洞（比如删过中间记录），这条语句可能返回空或偏少——这不是 bug，是设计取舍； - 该查询能走
PRIMARY KEY索引，EXPLAIN 显示type: range，耗时稳定在 0.01–0.03 秒（百万级表）。
要取多条随机数据？别用多次单条查询
执行 N 次上面的单条语句，N 越大，重复概率越高，且网络和解析开销翻倍。更实用的做法是：
- 先用应用层（PHP/Python/Go）生成 N 个不重复的随机整数，范围在
[MIN(id), MAX(id)]； - 拼成
WHERE id IN (123, 456, 789, ...)查询； - 如果怕空洞导致查不到足够数量，加一层重试：查出 K 条（K
- 注意
IN列表不宜过长（MySQL 默认max_allowed_packet限制），超过 1000 个 ID 建议分批。
空洞严重或无序主键时怎么办
比如用 UUID 当主键、或高频删用户导致 id 空洞率 >30%，上面基于范围的方法失效概率高。这时要么：
- 建一张预计算的随机 ID 映射表：
CREATE TABLE rand_id_map (seq INT PRIMARY KEY, real_id BIGINT)，定期用后台任务填充（比如每天凌晨跑一次INSERT INTO rand_id_map SELECT @row:=@row+1, id FROM table_name JOIN (SELECT @row:=0) r ORDER BY RAND()）； - 或者改用
JOIN写法（比子查询略快）：SELECT t1.* FROM `table` AS t1 JOIN (SELECT FLOOR(RAND() * (SELECT MAX(id) FROM `table`)) AS id) AS t2 ON t1.id >= t2.id ORDER BY t1.id LIMIT 1;
但依然受空洞影响； - 终极方案：业务层缓存一批 ID（比如 Redis 里存 1 万个活跃用户 ID），随机抽，再查详情——把数据库压力转移到缓存。
真正难处理的不是语法怎么写，而是主键是否“可预测”。如果连 MIN(id) 和 MAX(id) 都不准（比如分库分表、逻辑删除为主），那就别硬扛 SQL 层随机，交给应用层兜底更可控。
