MySQL RAND() 效能優化深度解析：從全表掃描到 JOIN 子查詢毫秒級提速

MySQL 中 ORDER BY RAND() 或 WHERE ... = RAND() 會導致全表掃描、臨時表排序，效能極差。本文通過 7 組實測對比，證明將 RAND() 移入 JOIN 子查詢可將隨機查詢從秒級優化至毫秒級。

測試環境

• 表 t_innodb_random：393,216 行，id INT PRIMARY KEY（無顯式自增），idx_id 索引。
• 資料 id 亂序分佈。

對比測試結果摘要

核心優化原則

1. 將 RAND() 計算下推到衍生表（子查詢），使外層查詢變為常量/範圍等值/範圍查找。
2. 使用 JOIN 而非 WHERE 子查詢，優化器能將衍生表物化為常量表（type=system），外層走 ref 或 range。
3. 配合 LIMIT 終止掃描，避免全表掃描。

生產環境推薦寫法

隨機取 1 筆（等值）

SELECT id FROM `table` t1
JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM `table`)) AS nid) t2
  ON t1.id = t2.nid;

隨機取 N 筆（範圍 + LIMIT）

SELECT id FROM `table` t1
JOIN (SELECT RAND() * (SELECT MAX(id) FROM `table`) AS nid) t2
  ON t1.id > t2.nid
LIMIT N;

完全隨機 N 筆（多個隨機點）

SELECT id FROM `table` t1
JOIN (SELECT ROUND(RAND() * (SELECT MAX(id) FROM `table`)) AS nid FROM `table` LIMIT N) t2
  ON t1.id = t2.nid;

避坑提醒

• RAND() 在同一查詢中多次呼叫會重新計算，衍生表確保只算一次。
• MAX(id) 子查詢會被優化器優化為常量（Select tables optimized away），無額外開銷。
• 若表有刪除導致 id 不連續，範圍法（id > nid）可能取不到精確 N 筆，可接受近似隨機；需精確則用等值法配合多隨機點。

掌握此模式，隨機抽樣不再是效能殺手。