order by rand() limit n 在数据量超几万行时极慢，因需全表扫描、每行计算随机数并全排序；推荐主键范围采样（如 where id in (...)）或 join 模拟偏移抽样，速度稳定毫秒级。
直接用 ORDER BY RAND() LIMIT 会慢得明显
当表数据量超过几万行，ORDER BY RAND() LIMIT N 会触发全表扫描 + 全排序，MySQL 必须为每一行生成随机数、排序、再取前 N 行——这不是“抽样”，是“暴力洗牌”。线上查 10 万行的用户表抽 10 条，响应可能从几毫秒飙到 2 秒以上。
RAND() 配合主键范围采样更可控
前提是表有自增 id（或其它连续、稀疏度低的整型主键），且无大量删除导致空洞。思路是：先估算主键范围，用 RAND() 生成 N 个落在该范围内的随机 id，再用 IN 查询。虽然不能保证一定返回 N 行（空洞会导致命中失败），但速度稳定在毫秒级。
实操步骤：
- 查出主键最小值和最大值：
SELECT MIN(id), MAX(id) FROM users; - 在应用层生成 N 个
FLOOR(RAND() * (max_id - min_id + 1)) + min_id的随机数（注意加min_id偏移） - 拼成
SELECT * FROM users WHERE id IN (123, 456, ...)查询 - 若返回行数不足 N，可多生成 20%~30% 的随机 ID 再去重重试
用 JOIN 模拟均匀采样（适合大表且不要求严格随机）
如果只要近似随机、且能接受少量偏差，这个技巧很实用：SELECT * FROM users AS t1 JOIN (SELECT FLOOR(RAND() * COUNT(*)) AS r FROM users) AS t2 ON t1.id >= t2.r LIMIT N;。它本质是取“第 r 行起的连续 N 行”，因 RAND() 只算一次，性能几乎不随表大小增长。
但要注意：
- 必须有主键或唯一索引，否则
t1.id >= t2.r可能匹配不到或重复 - 若主键不连续（比如删过大量数据），实际跳过的行数会偏多，抽样结果倾向靠后
-
COUNT(*)本身在大表上也有开销，可缓存或用近似值替代
真正需要严格随机且大数据量？别硬扛 MySQL
MySQL 不是随机抽样引擎。当表超百万、又要求“无偏且可复现”的随机样本时，把数据导出到 Python（用 pandas.sample() 或 random.sample()）或 ClickHouse（TABLESAMPLE）更靠谱。硬在 MySQL 里写复杂子查询或临时表，维护成本高、执行计划难预测，还容易被优化器误判。
最容易被忽略的一点：RAND() 在同一个 SQL 语句中多次调用，**每次返回不同值**——所以 WHERE RAND() 是概率采样，但 <code>ORDER BY RAND(), RAND() 会让排序逻辑不可控，千万别这么写。
