子查询 + rand() 比 order by rand() 快得多，因后者每行调用 rand() 并全表排序，而前者仅子查询算一次随机值，主查询靠索引范围扫描避开排序。
为什么子查询 + RAND() 比 ORDER BY RAND() 快得多
因为 ORDER BY RAND() 会对**每一行都调用一次 RAND()，再全表排序**，10 万行以上基本卡住；而子查询方案只在子查询里算一次随机值，主查询靠索引范围扫描（如 WHERE id >= ?），完全避开排序开销。
常见错误现象：SELECT * FROM users ORDER BY RAND() LIMIT 10 在生产环境从 20ms 涨到 8s，慢查询日志高频出现。
适用场景：主键是自增 INT、无大量删除（空洞少）、数据量中等（10 万～50 万行）。
关键限制：不能用于 UUID 或非数字主键；若 id 有严重空洞（比如删了 80% 记录），抽样会明显偏向高 ID 区域。
最稳的子查询写法：JOIN + FLOOR(RAND() * MAX(id))
这是实测在 30 万行表上稳定 0.014s 的写法，比 ORDER BY RAND() 快 40 倍以上：
SELECT t1.* FROM users t1 JOIN (SELECT FLOOR(1 + RAND() * (SELECT MAX(id) FROM users)) AS random_id) t2 ON t1.id >= t2.random_id ORDER BY t1.id LIMIT 10;
说明：
-
FLOOR(1 + RAND() * MAX(id))确保随机 ID 至少为 1，避免id=0导致无结果 -
ON t1.id >= t2.random_id配合ORDER BY t1.id，保证取到连续、可预期的 N 条记录 - 必须加
ORDER BY t1.id，否则OFFSET类行为不稳，可能漏行或重复 - 如果要抽 100 条，
LIMIT 100即可，无需改子查询逻辑
抽多条但要避免空洞导致数量不足
上面的 JOIN 写法在空洞多时可能返回少于 LIMIT 指定的数量（比如只返回 7 条，而非 10 条）。真正需要「严格 N 条」时，得补足：
- 用应用层生成 N 个独立随机 ID：
FLOOR(RAND() * MAX(id)) + 1，去重后拼成IN列表 - 示例（抽 3 条）：
SELECT * FROM users WHERE id IN ( FLOOR(1 + RAND() * (SELECT MAX(id) FROM users)), FLOOR(1 + RAND() * (SELECT MAX(id) FROM users)), FLOOR(1 + RAND() * (SELECT MAX(id) FROM users)) );
- 注意：该语句可能返回少于 3 行（因 ID 不存在），需在代码里检查
result.length并循环重试或 fallback 到 JOIN 方案 - 别用
ROUND()—— 它可能让最大 ID 被截断为 0，导致全表扫
容易被忽略的事务与复制一致性问题
RAND() 在同一个事务中多次调用会复用相同种子，导致子查询和主查询拿到一样随机值；从库延迟时，MAX(id) 可能比主库小，抽样结果不一致。
真实线上要注意：
- 子查询里的
(SELECT MAX(id) FROM users)最好提前查好缓存，避免每次执行都触发一次全表扫描 - 如果业务允许轻微偏差，可用
information_schema.TABLES.TABLE_ROWS快速估算行数（误差 10% 内），省掉MAX(id)查询 - 不要在长事务里反复执行这类 SQL；高一致性要求场景，直接切到应用层生成随机 ID +
IN查询更可控
