• 优点：真・随机，由于用了 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);

其实这就是 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 的数据同步（也就是经典的缓存一致性问题）。
  
  

最终总结：选型指南

那这几种方案怎么选？

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

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

参考文章：原文链接​