為什麼不建議使用 ORDER BY RAND()？

在 MySQL 中獲取隨機記錄，最直觀的寫法是 SELECT * FROM table ORDER BY RAND() LIMIT 1。然而，這句語法在數據量達到幾萬條時尚可接受，一旦突破百萬甚至千萬級，性能會急劇下降。原因在於 ORDER BY RAND() 會為每一行生成隨機數並進行全表排序，導致臨時表創建與文件排序，I/O 開銷極大。

高效隨機查詢的三種核心優化方案

方案一：應用層生成隨機 ID（推薦簡單場景）

將隨機邏輯下沉到應用層（如 PHP、Java），避免資料庫執行複雜計算。

// 1. 獲取最大 ID
$maxId = $pdo->query("SELECT MAX(id) FROM `table`")->fetchColumn();
// 2. 應用層生成隨機數
$randomId = mt_rand(1, $maxId);
// 3. 查詢大於等於該 ID 的第一條記錄
$sql = "SELECT * FROM `table` WHERE id >= {$randomId} LIMIT 1";

優點：SQL 極簡，資料庫無額外負擔。
缺點：若 ID 不連續（有刪除記錄），可能導致分佈不均，需配合 WHERE id >= ... 取最近一條彌補。

方案二：純 SQL 子查詢優化（無需應用層配合）

利用 MAX(id) 與 RAND() 在資料庫內部完成隨機點定位，避免全表掃描。

SELECT * 
FROM `table` 
WHERE id >= (
    SELECT CEIL(RAND() * (SELECT MAX(id) FROM `table`))
)
LIMIT 1;

關鍵點：
1. 內層 SELECT MAX(id) 只掃描索引，極快。
2. CEIL(RAND() * max_id) 生成隨機基準點。
3. 外層 WHERE id >= ... LIMIT 1 利用主鍵索引定位，僅掃描極少行數。

方案三：JOIN 衍生表法（適用於複雜條件）

當需要帶條件篩選（如 WHERE status=1）時，可結合衍生表實現高效隨機。

SELECT t1.* 
FROM `table` AS t1
JOIN (
    SELECT ROUND(RAND() * (SELECT MAX(id) FROM `table`)) AS rand_id
) AS t2 ON t1.id >= t2.rand_id
WHERE t1.status = 1  -- 可加入業務條件
ORDER BY t1.id ASC
LIMIT 1;

此法將隨機點計算與業務查詢解耦，索引利用率高。

避坑指南與最佳實踐

• ID 不連續問題：上述方案假設 ID 大致連續。若存在大量刪除導致空洞，可考慮維護一張「有效 ID 映射表」或使用 ROW_NUMBER()（MySQL 8.0+）生成連續序號。
• 多條隨機記錄：需取 N 條時，建議生成 N 個隨機點分別查詢，或使用 UNION ALL 合併多次單條查詢，避免單次大偏移。
• 測試驗證：上線前務必用 EXPLAIN 檢查執行計劃，確認 type=range 或 ref，而非 ALL。

總結

拒絕 ORDER BY RAND()，根據業務場景選擇「應用層隨機 ID」或「SQL 子查詢/JOIN」方案，可將千萬級數據的隨機查詢從秒級降至毫秒級，顯著提升系統吞吐量。