在日常开发中，我们经常会想要“随手抓一把”——比如抽奖、推荐、轮播图，这时Zui直观的写法往往是：

SELECT * FROM products ORDER BY RAND LIMIT 10;

kan似优雅，却暗藏致命的“定时炸弹”。本文将从底层原理、真实案例以及可落地的替代思路三个维度，带你彻底摆脱这颗隐藏在 SQL 里的雷。

MySQL 在执行上述语句时会先遍历目标表的每一行，为每条记录调用一次 RAND，生成一个介于 0~1 的小数，然后把这些数放进临时结构里排队等候排序。想象一下你让十万本书每本dou贴上一个随机标签，再把它们全部搬到另一间仓库重新排队——这可是极耗资源的活儿。

生成完随机值后MySQL 必须对整个结果集进行一次全局排序，Ru果数据量Yi经达到了几百万甚至上亿条，这一步骤往往会导致 CPU 使用率飙至 90%+，并且可Neng因为内存不足而创建磁盘临时表——磁盘 I/O 的噪声随之疯狂敲击硬盘。

当成千上万的请求同时触发这种查询时每个请求dou要经历同样的“全表扫描+排序”过程，CPU、内存、连接池瞬间被压垮。某大型电商在双十一期间就曾因大量页面使用 ORDER BY RAND 导致连接池枯竭，用户页面卡死、下单失败，直接把原本Ke以抢到手的订单变成了“空中楼阁”。

Ru果业务Neng够接受一次性读取所有主键再Zuo随机挑选，这种方式Zui快捷且不涉及数据库内部计算。

List allIds = productMapper.selectAllIds; // SELECT id FROM products;
Collections.shuffle;                     // 打乱顺序
List sample = allIds.subList;      // 取前 N 条
List result = productMapper.selectByIds;

适用场景：数据量在几千到几万之间；对实时性要求不高；服务器内存充足。

利用自增主键的有序特性，在应用层先算出Zui小/Zui大 ID，然后生成一个落在该范围内的随机值，再通过索引快速定位：

SELECT MIN AS min_id, MAX AS max_id FROM products;
-- 假设得到 min_id=1000, max_id=5000000
int randomId = minId + new Random.nextInt;
SELECT * FROM products WHERE id>= ? ORDER BY id LIMIT 10;

优势：只走索引，不会出现全表扫描；CPU 占用极低。

注意：ID 分布若出现大量空洞，需要配合 “>=” 条件或循环尝试，以免抽到不存在的记录。

将符合业务条件的 ID 存入 Redis Set，然后直接让 Redis 抽取所需数量：

Jedis jedis = new Jedis;
List ids = productMapper.selectIdsByStatus;
for  {
    jedis.sadd;
}
Set randIds = jedis.srandmember;
String sql = "SELECT * FROM products WHERE id IN (" +
             String.join + ")";
List list = jdbcTemplate.query;
jedis.close;

适合：高并发、大流量场景；缓存命中率高；Ke以通过定时任务或消息队列保持同步。

挑战：需要额外维护缓存一致性，但相较于数据库直接压力，这点成本是Ke以接受的。

将超大表按主键划分为若干段，每次先随机挑选一个段，再在该段内部使用 ORDER BY RAND. 因为段内记录数远小于全表，所以排序开销被显著削减。

SET @segment_size = 100000;               -- 每段十万行
SET @segment_cnt   = CEIL FROM products)/@segment_size);
SET @rand_seg      = FLOOR*@segment_cnt);
SET @start_id      = @rand_seg * @segment_size;
SELECT * FROM products
WHERE id BETWEEN @start_id AND @start_id + @segment_size
ORDER BY RAND
LIMIT 10;

P.S.: 段大小需要根据业务“随机程度”和系统资源Zuo调优；太小会导致热点集中，太大又恢复不了原有问题。

离线脚本周期性生成一批 “伪随机”ID 并写入专用表或缓存，然后业务直接从这里抽取。这种方式彻底把计算搬到了后台批处理阶段，前端请求只负责一次普通的 IN 查询。

-- 假设有一张 temp_random_ids
INSERT INTO temp_random_ids
SELECT FLOOR*)+min_id
FROM  AS min_id, MAX AS max_id FROM products) t
LIMIT 10000;
-- 前端查询示例
SELECT * FROM products WHERE id IN ;

Situtation: 极端高并发场景下可将这张临时表放进 Redis Sorted Set，只保留Zui近一次生成的数据，实现毫秒级响应。

- 从数据Ke以直观kan出，一旦摆脱了全表扫描与排序，CPU 与 I/O 的消耗立刻跌入低谷，即使面对突增流量，也Neng保持平稳。正因如此，阿里巴巴等大型互联网公司才会在《Java 开发手册》中明令禁止使用 TABLE_ORDER_BY_RAND.

# 数据规模 # — If 表记录少于 ~20 万，你Ke以考虑直接用 Application Shuffle 或者偶尔一次性的 ORDER BY RAND 来省事。

# 随机程度 # — If 对均匀性要求极高，推荐使用预生成 ID 表或 Redis SRANDMEMBER，它们天然具备无偏抽样特性。

# 高并发 # — N 秒级响应是硬指标时请务必走缓存层或者分段采样，把计算前置到离线任务中去。

# 数据倾斜 # — ID Ru果存在大量空洞，需要结合 “>= randomId” 或者二次回滚策略，否则可Neng出现抽不到记录的问题。

# 运维成本 # — Caching & Pre‑gen 两种方式dou要额外监控缓存失效和同步延迟，否则会出现“脏数据”。但相对而言，它们带来的收益往往远超维护成本。

A 公司在“双十一”前夕发现首页商品轮播加载时间从原来的 "5~12 秒", 突然飙升至近 "30 秒", 日志里满屏 “CPU usage>90%”。经排查发现核心 SQL 正是：