在程序员的职业生涯中，总有那么几个瞬间是让人“脊背发凉”的。比如当你还在为自己写出了一条简洁优雅的 SQL 语句而沾沾自喜时隔壁的 DBA却突然抱头蹲防，或者监控大屏上的 CPU 曲线突然拉出一条直冲云霄的红线。而这一切的始作俑者，往往就是那个kan起来人畜无害、实则剧毒无比的函数——ORDER BY RAND。

Ru果你翻阅过那本红宝书——《阿里巴巴 Java 开发手册》，你一定会在 MySQL 数据库规约章节kan到那条醒目的红线：不得在 database 中使用 ORDER BY RAND 进行随机排序。

hen多人第一反应是：“不就随机查几条数据吗？MySQL 既然提供了这个内置函数，为什么不让用？这不是大材小用吗？”

今天我们就来扒一扒，为什么这个函数是性Neng杀手界的“卧龙凤雏”，以及在海量数据下我们该如何优雅且高性Neng地实现“随机推荐”功Neng，而不是让数据库在深夜里为你报警。

那个让 DBA 暴跳如雷的 SQL

让我们先kankan这条“罪魁祸首”的长相：

SELECT * FROM product ORDER BY RAND LIMIT 3;

简洁、直观、kan似完美。当你的商品表只有几百条数据时它确实是省时省力的小甜甜；一旦数据量突破十万级，它立马变身吸干 CPU 的“牛夫人”，分分钟让你的数据库实例卡死。

我在测试环境重现了一下顺手敲了个 EXPLAIN。好家伙，Extra 字段里赫然写着：

Using temporary; Using filesort

这简直是 MySQL 性Neng的噩梦。这意味着数据库为了执行这个查询，不得不创建一个临时表，并且还要在临时表上执行一次文件排序。这还没完，RAND 这个函数Zui坑的地方在于，它会被每一行数据调用一次。

想象一下你的表里有 100 万行数据。MySQL 必须把这 100 万行数据全部捞出来为每一行生成一个随机数，然后根据这个随机数对这 100 万行进行排序，Zui后扔掉前面的 999,997 行，只取你想要的 3 行。这简直就是为了喝杯牛奶，养了一头奶牛，还顺便建了个牧场。

既然不Neng用，那该怎么办？

既然 ORDER BY RAND 被判了死刑，那业务需求里的“随机推荐”、“幸运抽奖”还得Zuo啊。其实思路hen简单：把“计算随机”的压力从 Database 转移到 Application，或者减少数据库的扫描行数。

这里整理了五种常见的替代方案，每种方案dou有自己的脾气和适用场景，且听我慢慢道来。

方案一：应用层 Shuffle

核心思想既然数据库随机排序慢，那我把 ID 全拿出来在 Java 代码里洗牌行不行？

适用场景数据量不大，内存不值钱，且对随机性要求极高。

Java 逻辑处理：

// 1. 查出所有商品ID
// SQL: SELECT id FROM product;
List allProductIds = productMapper.selectAllIds;
// 2. 利用 Java 的 Collections 工具类进行洗牌
Collections.shuffle;
// 3. 截取前3个
List randomIds = allProductIds.subList;
// 4. 回表批量查询详情
// SQL: SELECT * FROM product WHERE id IN ;
List results = productMapper.selectByIds;

优缺点点评

优点真・随机。由于用了 Collections.shuffle，随机分布非常均匀；逻辑简单粗暴，开发Zui快。

缺点太占内存。Ru果表里有 100 万条 ID，全拉到内存里JVM 直接 OOM 教Zuo人。

避坑指南一定要给 ID 列表加缓存，别每次请求dou去查全量 ID，那跟直接攻击数据库没区别。

方案二：Limit 偏移法

核心思想给所有数据编个号，随机生成一个“偏移量”，直接跳到那里去拿。

适用场景数据量大，对随机性要求没那么严苛，只要“kan起来”是随机的就行。

Java 逻辑处理：

// 1. 先查询总数
// SQL: SELECT COUNT FROM product;
int totalCount = productMapper.count;
// 2. 随机生成一个偏移量
// 注意：totalCount - 3 是为了防止 limit 越界，确保Neng取够3条
int offset = new Random.nextInt;
// 3. 直接利用 LIMIT 偏移量查询
// SQL: SELECT * FROM product LIMIT #{offset}, 3;
List results = productMapper.selectByOffset;

优缺点点评

优点性Neng极佳！大部分情况下只需要扫描 offset + 3 行。count 值Ke以放缓存中，定期geng新。

缺点

伪随机你取出来的 3 条数据是物理上连续的。比如正好取出了“iPhone 13, iPhone 14, iPhone 15”，kan起来不够随机，用户体验可Neng觉得这推荐系统有毛病。

深分页问题Ru果随机到的 offset hen大，LIMIT 9000000, 3 的性Neng也会下降，因为 MySQL 要先扫过前 900 万行扔掉。

方案三：多次查询法

核心思想既然方案二取出的数据是连续的，那我多随机几次每次取 1 条，拼凑出 3 条不就行了？

适用场景数据量大，且要求高质量随机，Neng接受稍微多一点的数据库查询开销。

Java 逻辑处理：

// 1. 获取总数
int total = productMapper.count;
// 2. 生成3个不重复的随机下标
List randomOffsets = new Random
        .ints // 生成无限流
        .distinct     // 去重
        .limit       // 截取前3个
        .boxed
        .collect);
// 3. 循环查询
List result = new ArrayList<>;
for  {
    // SQL: SELECT * FROM product LIMIT #{offset}, 1
    result.add);
}

其实这就是 MySQL 45讲 里推荐的优化思路。相比于方案二，它打散了连续性。

优缺点点评

优点解决了数据连续的问题，随机性geng好。

缺点Ru果随机到的 offset douhen大，数据库依然要扫描大量数据。而且交互次数从 1 次变成了 N 次网络开销也会增加。

方案四：ID 范围法

核心思想既然 LIMIT N, M 越往后越慢，那我直接算出随机 ID，用主键索引“跳”过去不就完事了？

适用场景ID 必须是连续的，追求极致性Neng。

Java 逻辑处理：

// 1. 获取 ID 范围
// SQL: SELECT MIN, MAX FROM product;
long minId = productMapper.selectMinId;
long maxId = productMapper.selectMaxId;
// 2. 计算随机起点
// 注意：maxId - minId - 3 是为了保证起点的 id 后面至少还有 3 条数据
// Ru果 ID 极其稀疏，这个范围可Neng需要预留geng大
long range = maxId - minId - 3; 
long randomId = minId +  * range);
// 3. 执行查询
List products = productMapper.selectGtId;

SQL 实现：

SELECT * FROM product WHERE id>= #{randomId} LIMIT 3;

优缺点点评

优点速度快到飞起！复杂度直接降为 $O$，完全没有 LIMIT 深分页的性Neng衰减。

缺点非常挑食！ 它假设 ID 是连续的。Ru果你的商品表里因为删删改改导致 ID 中间空洞hen大，这类 SQL 会导致分布严重不均，甚至可Neng取不到数据。

方案五：Redis 预处理法

核心思想既然 MySQL 不擅长Zuo随机，那就别难为它了交给Zui擅长的 Redis。

适用场景高并发、高性Neng、大数据量，标准的互联网大厂打法。

我们Ke以把所有有效的商品 ID 预先加载到 Redis 的 Set 或 List 结构中。

伪代码逻辑：

// 伪代码
var randomIds = redis.SRandMember;
var items = db.Query;

优缺点点评

优点性Neng无敌。Redis 基于内存，SRANDMEMBER 时间复杂度极低，完全不影响 MySQL 主库。

缺点架构变复杂了。需要维护 Redis 和 MySQL 之间的数据一致性，这属于“空间换时间”的典型操作。

到底该怎么选？

kan了这么多方案，是不是有点眼花缭乱？其实技术选型从来没有银弹，只有Zui适合当前业务场景的妥协。

为了方便大家记忆，我简单整理了一个选择指南：

数据量 <10W别犹豫了直接用方案一。开发Zui快，逻辑Zui简单，随机性Zui完美，维护成本Zui低。

数据量> 10W，ID 连续方案四是你的首选。性Neng强悍，代码量也不大。

数据量> 10W，ID 不连续Ru果对随机性要求一般，方案二凑合Neng用；Ru果要求高，老老实实上 方案五。

高并发大厂场景必须 方案五。这时候哪怕多一次网络交互，dou比把数据库打挂要好。

Zui后 提醒各位同学：写代码的时候，多kankan数据量级，多想想Zui坏情况。别让一行 ORDER BY RAND，成为你深夜被叫起来修 Bug 的理由。毕竟MySQL 45讲 里推荐的每一个优化思路，dou是前人踩过的坑啊。

---