ORDER BY RAND()在大表上必须避开，因其需全表扫描、每行计算RAND()并全量排序，导致IO和CPU双爆，百万级表响应从毫秒跃至秒级甚至超时；替代方案包括主键范围随机查询、应用层随机ID回表、COUNT+OFFSET偏移法等。
别用 ORDER BY RAND()，除非表只有几百行。 它在万级以上数据量就会明显变慢，百万级基本不可用——不是“有点慢”，是会拖垮整个查询线程。
为什么 ORDER BY RAND() 在大表上必须避开
MySQL 执行 SELECT * FROM t ORDER BY RAND() LIMIT 5 时，会为每一行调用一次 RAND()，再全表排序。100 万行 = 100 万个随机数 + 一次百万级排序。磁盘 I/O 和 CPU 都吃满，响应从毫秒跳到秒级甚至超时。EXPLAIN 会显示 Using filesort，且无法走任何索引。
常见错误现象：SELECT * FROM orders WHERE status = 'paid' ORDER BY RAND() LIMIT 10 在订单表超 50 万后，经常触发慢查询告警或连接超时。
适用场景仅限：配置表、字典表、测试用小表（COUNT(*) ）；生产环境的 <code>user、log、order 类表一律禁用。
用主键范围采样：快但得防 ID 空洞
前提是表有自增 id，且删除不频繁（ID 分布相对均匀）。核心是绕过排序，直接靠主键索引定位。
- 先查边界：
SELECT MIN(id), MAX(id) FROM your_table WHERE condition - 应用层生成 N 个
[min_id, max_id]内的随机整数（去重） - 拼成：
SELECT * FROM your_table WHERE id IN (123, 456, 789)
注意点：
- 如果空洞多（比如删了 30% 数据），
IN可能查不到足额记录，需多生成 20%~30% 的候选 ID，或补查一次 - 不能写成
WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM t)) LIMIT 5—— 这会返回连续 ID 段，不是均匀随机 - 该方法依赖主键索引，查询耗时基本恒定，
O(1)级别
用 COUNT(*) + LIMIT ... OFFSET：均匀但偏移越大越慢
适合对随机性要求严格（如抽奖、A/B 测试），且能接受一定性能衰减的场景。
- 先获取总数：
SELECT COUNT(*) FROM your_table WHERE condition - 应用层生成随机偏移：
offset = random_int(0, total_count - N) - 执行：
SELECT * FROM your_table WHERE condition LIMIT N OFFSET offset
风险提示：
-
COUNT(*)在 InnoDB 大表上可能慢（尤其没加 WHERE 或条件不走索引），可考虑用information_schema.TABLES.TABLE_ROWS近似值（误差允许时） -
OFFSET超过 10 万后，MySQL 仍要扫描前面所有行，耗时明显上升 - 该方式天然均匀，不依赖主键连续性，但两次查询 + 应用层计算，逻辑比单 SQL 稍重
真正难的不是选哪种方法，而是判断你的表是否真“连续”、空洞率多少、业务能否容忍少量重复采样或偏移偏差——这些没法靠 SQL 自动感知，得你去看 SELECT COUNT(*), COUNT(id) FROM t 和 SELECT MAX(id)-MIN(id)+1 - COUNT(*) 才知道空洞比例。
