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<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偏移量

實現思路

1. 獲取總數據量
2. 計算隨機偏移量
3. 使用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講方案）

實現思路

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偏移量或多重查詢方案，才能在保證隨機性的同時提供良好的系統性能。

技術選型建議：對於大多數電商場景，方案一（應用層隨機）是最佳選擇，既能保證真正的隨機性，又具有穩定的高性能表現。