【MySQL优化】扔掉ORDER BY RAND()！随机推荐的性能提升方案
背景与需求分析
在电商平台开发中，我们经常需要实现“随机推荐”功能：从商品库中随机选取指定数量的商品展示给用户。假设商品表（product）有10000条数据，需要随机获取3个不重复的商品。
许多开发者第一反应是使用 ORDER BY RAND() 实现（如果你不知道，那当我没说），但这种方法的性能代价极高，在处理大量数据时几乎不可用。
为什么不推荐使用ORDER BY RAND()？
-- 常见但不推荐的方案
SELECT * FROM product ORDER BY RAND() LIMIT 3;
这条SQL语句的问题在于：
需要全表扫描：MySQL必须读取所有行并为每行分配随机值
使用临时表：需要创建临时表存储所有数据
文件排序：需要对整个临时表进行排序
性能随数据量增长急剧下降：万级数据尚可勉强接受，十万级以上几乎不可用
执行计划中会出现"Using temporary"和"Using filesort"，这些都是性能杀手。
高性能替代方案
方案一：应用层随机（推荐首选）
实现思路
获取所有商品ID
在应用层进行随机洗牌
取前3个ID回表查询完整信息
具体实现
-- 第一步：获取所有商品ID（只需执行一次并可缓存）
SELECT id FROM product;
// 第二步：Java应用层处理随机逻辑
List<Integer> productIdList = getProductIdsFromCacheOrDB(); // 从缓存或数据库获取ID列表
// 使用洗牌算法随机打乱顺序
Collections.shuffle(productIdList);
// 取前三个不重复ID
List<Integer> randomIds = productIdList.subList(0, 3);
// 第三步：回表查询完整商品信息
List<Product> randomProducts = productMapper.selectByIds(randomIds);
-- 回表查询的SQL
SELECT id, name, price, image_url
FROM product
WHERE id IN (?, ?, ?);
性能分析
扫描行数：10000（获取ID） + 3（回表查询）
优点：随机性最好，性能稳定
缺点：需要一次性获取所有ID，内存占用与数据量成正比
适用场景：数据量在可接受范围内（如10万条以下）
优化建议
对商品ID列表进行缓存，避免每次请求都查询数据库
可定期更新缓存，如每5分钟刷新一次ID列表
方案二：使用LIMIT偏移量
实现思路
获取总数据量
计算随机偏移量
使用LIMIT获取数据
具体实现
-- 第一步：获取总行数（可缓存）
SELECT COUNT(*) FROM product;
// 第二步：计算随机偏移量
int totalCount = getProductCount(); // 获取商品总数
Random random = new Random();
// 确保不会越界（-3是为了保证至少能取到3条数据）
int offset = random.nextInt(totalCount - 3);
// 第三步：执行分页查询
List<Product> randomProducts = productMapper.selectWithOffset(offset, 3);
-- 分页查询SQL
SELECT id, name, price, image_url
FROM product
LIMIT #{offset}, 3;
性能分析
扫描行数：10000（计数查询） + offset + 3
优点：相比ORDER BY RAND()性能大幅提升
缺点：随机性不够理想（获取的是连续数据），偏移量越大性能越差
适用场景：数据量大但对随机性要求不高的场景
方案三：多次查询取结果（MySQL 45讲方案）
实现思路
获取总数据量
生成多个随机偏移量
多次查询获取随机行
具体实现
-- 获取总行数
SELECT COUNT(*) INTO @C FROM product;
-- 生成三个随机偏移量
SET @Y1 = FLOOR(@C * RAND());
SET @Y2 = FLOOR(@C * RAND());
SET @Y3 = FLOOR(@C * RAND());
-- 执行三次查询（实际应用中应在代码中处理）
SELECT * FROM product LIMIT @Y1, 1;
SELECT * FROM product LIMIT @Y2, 1;
SELECT * FROM product LIMIT @Y3, 1;
// Java中的实现方式
int totalCount = productMapper.selectCount();
Random random = new Random();
int id1 = random.nextInt(totalCount);
int id2 = random.nextInt(totalCount);
int id3 = random.nextInt(totalCount);
// 注意：需要处理可能重复的情况
while (id2 == id1) {
id2 = random.nextInt(totalCount);
}
while (id3 == id1 || id3 == id2) {
id3 = random.nextInt(totalCount);
}
Product p1 = productMapper.selectWithOffset(id1, 1);
Product p2 = productMapper.selectWithOffset(id2, 1);
Product p3 = productMapper.selectWithOffset(id3, 1);
性能分析
扫描行数：10000 + Y1 + Y2 + Y3 + 3
优点：随机性较好
缺点：需要多次查询，可能产生重复需要处理
适用场景：数据量较大且需要较好随机性的场景
方案对比
方案 随机性 性能 实现复杂度 适用场景
ORDER BY RAND() 优 差 简单 不推荐用于生产环境
应用层随机 优 优 中等 数据量适中（推荐）
LIMIT偏移量 中 良 简单 数据量大，随机性要求不高
多次查询 良 中 复杂 数据量大，需要较好随机性
实际应用建议
数据量小于10万：推荐使用方案一（应用层随机），平衡了性能与随机性
数据量大于10万：可考虑方案二（LIMIT偏移量），但需要注意：
使用WHERE条件缩小范围后再随机
结合缓存减少数据库压力
超大数据量：考虑使用专门的推荐系统或预处理机制
预先为每个用户生成推荐结果
使用Redis等缓存随机推荐结果
随机性要求极高：可考虑组合方案
使用方案一获取随机ID
对极端情况（如重复推荐）做特殊处理
扩展思考
加权随机：如何实现基于热度、评分等权重的随机推荐？
去重机制：如何避免用户看到已购买或已浏览过的商品？
分布式环境：在分库分表环境下如何高效实现随机推荐？
总结
随机推荐功能虽然看似简单，但在海量数据下实现高性能并非易事。ORDER BY RAND() 虽然写法简洁，但性能代价过高，不适用于生产环境。根据实际数据量和业务需求，选择应用层随机、LIMIT偏移量或多重查询方案，才能在保证随机性的同时提供良好的系统性能。
技术选型建议：对于大多数电商场景，方案一（应用层随机）是最佳选择，既能保证真正的随机性，又具有稳定的高性能表现。