SQL 性能避坑：为什么阿里强制禁用 ORDER BY RAND()？

MySQL专栏

如果你翻阅过《阿里巴巴 Java 开发手册》，在 MySQL 数据库规约中，一定见过这条醒目的“红线”：

【强制】不得在 database 中使用 ORDER BY RAND() 进行随机排序。

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

事实上，这可能是 MySQL 里最“坑爹”的内置函数之一。在数据量只有几百条时，它是省时省力的小甜甜；一旦数据量突破十万级，它立马变身吸干 CPU 的“牛夫人”，分分钟让你的数据库报警。

今天我们就来扒一扒，为什么这个函数是性能杀手，以及在海量数据下，我们该如何优雅且高性能地实现“随机推荐”功能。

案发现场：一条 SQL 引发的血案

那个让 DBA 暴跳如雷的 SQL 长这样：

-- 看起来人畜无害，实则剧毒无比
SELECT * FROM product ORDER BY RAND() LIMIT 3;

如果你的商品表只有几百条数据，怎么玩都行。但当数据量达到 几万、几十万甚至上百万 时，这条 SQL 就是一颗定时炸弹。

为什么它这么慢？

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

Using temporary; Using filesort

这简直是 MySQL 性能杀手界的“卧龙凤雏”！

ORDER BY RAND() 的执行流程大致是这样的：

1. 全表扫描：MySQL 需要为每一行数据生成一个随机值。
2. 创建临时表：把查询列和对应的随机值塞进临时表（如果内存不够，还会用到磁盘临时表）。
3. 全局排序：对临时表里的随机值进行排序。
4. 取出前几条：这就好比你要从一袋米里随机挑 3 粒，却先把整袋米倒出来，给每粒米编个号，排个序，再挑前 3 个。

这不崩谁崩？

---

深入剖析：五种高性能替代方案

既然 ORDER BY RAND() 不能用，那怎么实现“随机推荐”？其实思路很简单：把“计算随机”的压力从 Database 转移到 Application（应用层），或者减少数据库的扫描行数。

方案一：应用层随机法（Application Shuffle）

适用场景：数据量不大（例如 < 10万），内存不值钱。

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

代码实现

// 1. 查出所有商品ID（只查ID，速度飞快）
// SQL: SELECT id FROM product;
List<Integer> allProductIds = productMapper.selectAllIds();

// 2. 利用 Java 的 Collections 工具类进行洗牌
Collections.shuffle(allProductIds);

// 3. 截取前3个
List<Integer> randomIds = allProductIds.subList(0, 3);

// 4. 回表批量查询详情
// SQL: SELECT * FROM product WHERE id IN (..., ..., ...);
List<Product> results = productMapper.selectByIds(randomIds);

优缺点点评

• 优点：真・随机，由于用了 Collections.shuffle，随机分布非常均匀；逻辑简单粗暴。
• 缺点：太占内存。如果表里有 1000 万条 ID，全拉到内存里，JVM 直接 OOM 教做人。
• 避坑：一定要给 ID 列表加缓存（Redis 或本地缓存），别每次请求都去查全量 ID，那跟直接攻击数据库没区别。

---

方案二：Limit 偏移法（Limit Offset）

适用场景：数据量大（百万级以上），对随机性要求没那么严苛。

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

代码实现

// 1. 先查询总数（可以走缓存）
// SQL: SELECT COUNT(*) FROM product;
int totalCount = productMapper.count();

// 2. 随机生成一个偏移量
// 注意：totalCount - 3 是为了防止 limit 越界，确保能取够3条
int offset = new Random().nextInt(totalCount - 3);

// 3. 直接利用 LIMIT 偏移量查询
// SQL: SELECT * FROM product LIMIT #{offset}, 3;
List<Product> results = productMapper.selectByOffset(offset, 3);

优缺点点评

• 优点：性能极佳！大部分情况下只需要扫描 offset + 3 行 ，count值可以放缓存中，定期更新。
• 缺点：
  1. 伪随机：你取出来的 3 条数据是物理上连续的。比如正好取出了“iPhone 13, iPhone 14, iPhone 15”，看起来不够随机。
  2. 深分页问题：如果随机到的 offset 很大（比如 900万），LIMIT 9000000, 3 的性能也会下降，因为 MySQL 要先扫过前 900 万行扔掉。

---

方案三：多次查询法（Multiple Queries）

适用场景：数据量大，且要求高质量随机。

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

代码实现

// 1. 获取总数
int total = productMapper.count();

// 2. 生成3个不重复的随机下标（Java 8 Stream 写法）
List<Integer> randomOffsets = new Random()
        .ints(0, total) // 生成无限流
        .distinct()     // 去重
        .limit(3)       // 截取前3个
        .boxed()
        .collect(Collectors.toList());

// 3. 循环查询（或者拼接 SQL 用 UNION ALL）
List<Product> result = new ArrayList<>();
for (Integer offset : randomOffsets) {
    // SQL: SELECT * FROM product LIMIT #{offset}, 1
    result.add(productMapper.selectByLimit(offset, 1));
}

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

优缺点点评

• 优点：既避免了全表排序，又保证了较好的随机性。
• 缺点：要与数据库交互多次（N 次查询）。不过对于高并发应用，一般都是多次查询 + 缓存，这点开销完全可以接受。

方案四：主键范围法（Index Random）

适用场景：ID 必须这是连续的（或空洞很少），追求极致性能。

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

代码实现

Java 逻辑处理：

// 1. 获取 ID 范围（minId 和 maxId）
// SQL: SELECT MIN(id), MAX(id) FROM product;
long minId = productMapper.selectMinId();
long maxId = productMapper.selectMaxId();

// 2. 计算随机起点
// 注意：maxId - minId - 3 是为了保证起点的 id 后面至少还有 3 条数据（假设 ID 连续）
// 如果 ID 极其稀疏，这个范围可能需要预留更大
long range = maxId - minId - 3; 
long randomId = minId + (long)(Math.random() * range);

// 3. 执行查询
List<Product> products = productMapper.selectGtId(randomId, 3);

SQL 实现：

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

优缺点点评

• 优点：速度快到飞起！复杂度直接降为 $O(\log N)$（主键查找），完全没有 LIMIT 深分页的性能衰减。
• 缺点：非常挑食！ 它假设 ID 是连续的。如果你的商品表里因为删删改改导致 ID 中间空洞很大，这类 SQL 会导致分布严重不均（空洞前的那条数据被选中的概率会暴增），甚至可能取不到数据。

---

方案五：Redis 预处理法（Redis Set）

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

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

代码实现

// 1. 初始化（只需做一次）：把所有商品ID丢进 Redis Set
// Redis Key: "all_product_ids"

// 2. 利用 Redis 原生命令随机获取 ID
// 命令：SRANDMEMBER key count
// 时间复杂度：O(N)，N是你取的数量，极快
List<Integer> randomIds = redisTemplate.opsForSet().randomMembers("all_product_ids", 3);

// 3. 回表 MySQL 查详情（这里全是主键查询，性能无压力）
List<Product> products = productMapper.selectByIds(randomIds);

优缺点点评

• 优点：天花板级别的性能。无论你有多少数据，Redis 都基本能在几毫秒内吐出随机 ID。
• 缺点：架构变复杂了。你需要维护 Redis 和 MySQL 的数据同步（也就是经典的缓存一致性问题）。

---

最终总结：选型指南

那这几种方案怎么选？

你的场景	推荐方案	理由
数据量 < 10W	方案一（应用层 Shuffle）	开发最快，逻辑最简单，随机性最完美。
数据量 > 10W，ID连续	方案四（索引跳跃）	既不用维护缓存，又能享受极致性能。
数据量 > 10W，允许连续	方案二（Limit Offset）	性能不错，通用性强，是个老实人。
数据量 > 10W，要求打散	方案三（多次查询）	在性能和随机性之间找到了平衡点。
高并发 / 追求极致	方案五（Redis Set）	工业界标准答案，虽然稍微麻烦点，但真香。
想被辞退	ORDER BY RAND()	只要你敢用，P0 故障随时带回家。

最后多嘴一句：
如果你的业务可以接受“伪随机”（比如每个人看到的随机列表在 1 小时内是一样的），强烈建议把算好的随机结果丢进 Redis。毕竟，最好的 SQL 优化就是不执行 SQL。

别让你写的代码，成为深夜报警的罪魁祸首。