MySQL用RAND()直接LIMIT抽样会慢得离谱，因需为每一行计算随机值并全表排序，导致临时表和文件排序，I/O与CPU双高；小表可用，大表应改用其他抽样策略。
MySQL用RAND()直接LIMIT抽样会慢得离谱
当表数据量超过几万行，SELECT * FROM t ORDER BY RAND() LIMIT 10 就会明显变慢。原因不是RAND()本身，而是MySQL必须为**每一行都计算一次随机值**，再全表排序——即使你只要10条。这会导致临时表+文件排序，I/O和CPU双爆。
实操建议：
- 小表（ORDER BY RAND() LIMIT N，简单够用
- 中大表（≥5万行）务必避开全表
ORDER BY RAND() - 如果表有自增主键且连续（或基本连续），优先走主键区间采样
用主键范围+RAND()生成随机ID再JOIN查记录
核心思路：不排序全表，而是估算主键范围，用RAND()生成N个落在该范围内的ID，再用IN或JOIN捞出真实存在的记录。它快，但要注意ID稀疏性问题。
示例（假设主键是id，类型INT UNSIGNED）：
SELECT t1.* FROM tbl t1 INNER JOIN ( SELECT FLOOR(RAND() * (SELECT MAX(id) FROM tbl)) + 1 AS id FROM information_schema.tables LIMIT 10 ) t2 ON t1.id = t2.id;
关键点：
-
FLOOR(RAND() * MAX(id)) + 1保证ID在[1, MAX(id)]范围内，但若ID空洞多（比如删过大量数据），会查不到对应行，最终结果可能少于N条 -
information_schema.tables只是借个“无实际数据的驱动表”，避免FROM DUAL在旧版本不支持 - 若要求严格返回N条，需补漏逻辑（比如循环重试或改用其他策略）
用WHERE id IN (…)替代JOIN更简洁，但有长度限制
对N较小（如≤100）且ID分布尚可的场景，直接拼随机ID列表最直观：
SELECT * FROM tbl WHERE id IN ( SELECT FLOOR(RAND() * (SELECT MAX(id) FROM tbl)) + 1 FROM information_schema.tables LIMIT 10 );
注意：
- MySQL 8.0.19+ 支持子查询
IN，低版本需改写为JOIN或临时表 -
IN列表长度受max_allowed_packet和sort_buffer_size影响，超长会报错Packet too large - 仍存在空洞导致结果不足的问题，无法保证N条必现
真正稳定的方案：先用RAND()标记+LIMIT，再二次过滤去重
如果业务不能容忍“抽不到N条”，又不想引入应用层逻辑，可用两步法兜底：
SELECT * FROM ( SELECT *, RAND() AS r FROM tbl ORDER BY r LIMIT 100 -- 先取宽泛样本，比如N×10 ) t ORDER BY RAND() LIMIT 10;
说明：
- 第一步
LIMIT 100从全表快速捞出一个“足够大的随机子集”，避免全表排序开销 - 第二步在100条内再
ORDER BY RAND()，开销可忽略 - 比纯
ORDER BY RAND() LIMIT 10快数倍，且几乎总能拿到满额结果 - 适合N≤100、对绝对均匀性要求不苛刻的场景（比如后台运营抽样）
主键不连续、数据量大、又要求稳定返回N条时，这个折中方案最容易落地。别迷信一步到位的SQL，有时候加一层中间筛选，反而最省心。
