MySQL系列文章

面对海量数据随机推荐需求，如何平衡性能与随机性成为关键挑战

背景与需求分析

在电商平台开发中，我们经常需要实现“随机推荐”功能：从商品库中随机选取指定数量的商品展示给用户。假设商品表（product）有10000条数据，需要随机获取3个不重复的商品。

许多开发者第一反应是使用 ORDER BY RAND() 实现（如果你不知道，那当我没说），但这种方法的性能代价极高，在处理大量数据时几乎不可用。

为什么不推荐使用ORDER BY RAND()？

-- 常见但不推荐的方案
SELECT * FROM product ORDER BY RAND() LIMIT 3;

这条SQL语句的问题在于：

1. 需要全表扫描：MySQL必须读取所有行并为每行分配随机值
2. 使用临时表：需要创建临时表存储所有数据
3. 文件排序：需要对整个临时表进行排序
4. 性能随数据量增长急剧下降：万级数据尚可勉强接受，十万级以上几乎不可用

执行计划中会出现"Using temporary"和"Using filesort"，这些都是性能杀手。

高性能替代方案

方案一：应用层随机（推荐首选）

实现思路

1. 获取所有商品ID
2. 在应用层进行随机洗牌
3. 取前3个ID回表查询完整信息

具体实现

-- 第一步：获取所有商品ID（只需执行一次并可缓存）
SELECT id FROM product;

// 第二步：Java应用层处理随机逻辑
List productIdList = getProductIdsFromCacheOrDB(); // 从缓存或数据库获取ID列表

// 使用洗牌算法随机打乱顺序
Collections.shuffle(productIdList);

// 取前三个不重复ID
List randomIds = productIdList.subList(0, 3);

// 第三步：回表查询完整商品信息
List 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偏移量

实现思路

1. 获取总数据量
2. 计算随机偏移量
3. 使用LIMIT获取数据

具体实现

-- 第一步：获取总行数（可缓存）
SELECT COUNT(*) FROM product;

// 第二步：计算随机偏移量
int totalCount = getProductCount(); // 获取商品总数
Random random = new Random();

// 确保不会越界（-3是为了保证至少能取到3条数据）
int offset = random.nextInt(totalCount - 3);

// 第三步：执行分页查询
List 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讲方案）

实现思路

1. 获取总数据量
2. 生成多个随机偏移量
3. 多次查询获取随机行

具体实现

-- 获取总行数
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
• 优点：随机性较好
• 缺点：需要多次查询，可能产生重复需要处理
• 适用场景：数据量较大且需要较好随机性的场景

方案对比

实际应用建议

1. 数据量小于10万：推荐使用方案一（应用层随机），平衡了性能与随机性

2. 数据量大于10万：可考虑方案二（LIMIT偏移量），但需要注意：

   • 使用WHERE条件缩小范围后再随机
   • 结合缓存减少数据库压力

3. 超大数据量：考虑使用专门的推荐系统或预处理机制

   • 预先为每个用户生成推荐结果
   • 使用Redis等缓存随机推荐结果

4. 随机性要求极高：可考虑组合方案

   • 使用方案一获取随机ID
   • 对极端情况（如重复推荐）做特殊处理

扩展思考

1. 加权随机：如何实现基于热度、评分等权重的随机推荐？
2. 去重机制：如何避免用户看到已购买或已浏览过的商品？
3. 分布式环境：在分库分表环境下如何高效实现随机推荐？

总结

随机推荐功能虽然看似简单，但在海量数据下实现高性能并非易事。ORDER BY RAND() 虽然写法简洁，但性能代价过高，不适用于生产环境。根据实际数据量和业务需求，选择应用层随机、LIMIT偏移量或多重查询方案，才能在保证随机性的同时提供良好的系统性能。

技术选型建议：对于大多数电商场景，方案一（应用层随机）是最佳选择，既能保证真正的随机性，又具有稳定的高性能表现。