MySQL中RAND()抽样不准百分比且性能差，因ORDER BY RAND()需全表排序；应改用随机阈值过滤或应用层生成随机ID再IN查询，以避免空洞偏差和重复问题。
MySQL 中用 RAND() 抽样为什么常抽不准百分比？
直接写 SELECT * FROM t ORDER BY RAND() LIMIT 100 只能固定取行数，无法按表总行数的百分比动态抽样。更关键的是，ORDER BY RAND() 在大表上性能极差——它会为每一行计算随机值、全表排序，IO 和 CPU 开销爆炸，且 MySQL 无法用索引优化。
用 RAND() + 比例计算实现近似百分比抽样
核心思路：不排序，改用随机阈值过滤。假设要抽 5%，就让每行以 5% 概率被选中：
SELECT * FROM t WHERE RAND() < 0.05;
这个写法简单高效，但要注意：
-
RAND()在 WHERE 中对每行独立求值，不是单次生成后广播，所以概率行为符合预期 - 实际返回行数是二项分布，期望值 = 总行数 × 比例，但会有波动（比如 100 万行抽 1%，实际可能在 9800–10200 行之间）
- 不能用于需要严格精确行数的场景（如 A/B 测试配额控制）
- WHERE 条件中的
RAND()在 MySQL 8.0+ 中支持物化临时表优化，但老版本仍建议避免在大表上高频执行
想要严格 N% 行数？用子查询 + LIMIT 动态算数量
如果必须精确控制行数（比如“抽 3.7%”，四舍五入到整数），得先查总数，再算 LIMIT 值：
SELECT * FROM t ORDER BY RAND() LIMIT FLOOR((SELECT COUNT(*) FROM t) * 0.037);
注意几个现实约束：
- 子查询
(SELECT COUNT(*) FROM t)本身可能很慢，尤其没主键或 InnoDB 表无精确统计时 -
FLOOR()向下取整，CEILING()向上，按需选；小数部分丢弃可能导致实际比例略低于目标 - 两次全表扫描（一次 COUNT，一次 ORDER BY RAND）——大表慎用
- 若表有 WHERE 过滤条件，COUNT 和主查询的 WHERE 必须完全一致，否则样本基数错乱
生产环境更稳的替代方案：基于主键 ID 的随机跳读
当表有自增主键 id 且分布相对均匀时，可避开 RAND() 排序：
SELECT * FROM t WHERE id IN ( SELECT id FROM t WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) ORDER BY id LIMIT 100 );
但这只是折中解，真正上线前得确认：
- ID 是否存在大量空洞（如频繁删数据）？空洞多会导致抽样偏差甚至漏抽
- 是否允许少量重复？上面写法在边界处可能因
RAND()碰撞重复选同一段 - 更稳妥的做法是用应用层生成一批随机 ID（比如用 Python 的
random.sample(range(1, max_id), k=1000)），再拼 IN 查询——可控、可审计、不拖慢数据库
抽样逻辑越靠近业务层，越容易应对分布不均、权限隔离、跨分片等真实问题。数据库内置函数看着方便，但边界 case 往往藏在数据分布和执行计划里。
