order by rand() limit n 在大数据量下性能差，因其需全表扫描、逐行计算随机值并文件排序；应改用主键范围查询或预生成id策略，如 where id >= ceil(rand() * max(id)) order by id limit n。
直接用 ORDER BY RAND() LIMIT N 在数据量超过 1 万行时就会明显变慢，不是写法错，而是 MySQL 执行机制决定它必须为每一行计算随机值并全表排序——哪怕你只要 1 条。真要稳定高效抽 N 条，得绕开排序，改用主键范围跳查或预生成 ID 策略。
为什么 ORDER BY RAND() 会突然卡住
它不是“有点慢”，是执行路径本身不可扩展：全表扫描 → 每行调一次 RAND() → 全量文件排序（Using filesort）→ 再取 LIMIT。EXPLAIN 里一定出现 type: ALL 和 Extra: Using filesort。10 万行表耗时轻松破秒，100 万行可能超 5 秒，且无法利用任何索引。更糟的是，RAND() 是非确定性函数，连 Query Cache（如果还开着）都缓存不了。
用 WHERE id >= ... ORDER BY id LIMIT N 替代（最常用）
前提是你有自增/有序数字主键（如 id），且删除不频繁（空洞少）。核心是把“打乱全表”变成“找一个起点往后顺延”。
-
SELECT * FROM user WHERE id >= CEIL(RAND() * (SELECT MAX(id) FROM user)) ORDER BY id LIMIT 10是最简写法，实测 100 万行也能压在 0.02 秒内，EXPLAIN 显示type: range - 别写成
(SELECT MAX(id) FROM user) * RAND()—— 子查询会被反复执行；应写成RAND() * (SELECT MAX(id) FROM user)让子查询只算一次 - 若表
id从非 1 开始（比如最小是 1000），必须补上MIN(id)偏移，否则前段数据永远抽不到：WHERE id >= FLOOR(RAND() * ((SELECT MAX(id) FROM user) - (SELECT MIN(id) FROM user)) + (SELECT MIN(id) FROM user)) - 单次查询可能返回不足 N 条（因 ID 空洞），应用层最多重试 2–3 次即可补足
用 JOIN 随机生成 ID 再关联（适合中等空洞）
当 id 空洞较多（比如删过大量用户），纯 WHERE id >= 容易漏行，这时用 JOIN 把随机 ID 生成和主表查询解耦，稳定性更高。
- 典型写法：
SELECT t1.* FROM user AS t1 JOIN (SELECT FLOOR(RAND() * (SELECT MAX(id) FROM user)) + 1 AS id) AS t2 ON t1.id >= t2.id ORDER BY t1.id LIMIT 10 - 注意
information_schema.tables只是借个空驱动表，避免旧版 MySQL 不支持FROM DUAL；不要真去查information_schema的业务数据 -
FLOOR(RAND() * MAX(id)) + 1保证 ID 落在 [1, MAX(id)] 区间，但若空洞密集，仍可能查不到对应行，最终结果条数不稳定 - 高并发下慎用——每个查询都触发一次
MAX(id)查询，建议用 Redis 缓存该值（每分钟更新）
真正要严格 N 条且均匀，就得接受代价或改结构
如果业务要求绝对均匀随机（比如抽奖、审计抽样），上面两种方法都有轻微偏差（空洞处概率低），这时只有两个现实选择：
- 小表（≤5000 行）继续用
ORDER BY RAND() LIMIT N，加个查询超时保护即可 - 大表就建一张轻量
random_id_map表，后台定时把所有有效id打乱后插入，抽样时只在这张小表上ORDER BY RAND()—— 因为它只有 ID 列，几万行也不疼 - 或者改表结构：主键保留 UUID，另加一列
seq_id BIGINT AUTO_INCREMENT作为稠密序号，抽样就回到安全路径
最容易被忽略的点是：没确认主键是否真连续，就硬套 WHERE id >=；还有人把 RAND() 塞进 WHERE 子查询里，导致每次比较都重新计算，性能反而比直接 ORDER BY RAND() 还差。
