naïve 寫法及其災難性後果

SELECT * FROM table_name ORDER BY RAND() LIMIT 5;

問題：MySQL 需為每行生成隨機數、排序全表、再取前 N 行。百萬級資料會產生臨時表、檔案排序，耗時秒級甚至分鐘級。

優化演進之路

階段 1：利用主鍵 ID 範圍 + RAND() 取隨機起點

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

缺點：ID 不連續（刪除導致空洞）時，分布不均；且需掃描從隨機點到末尾的所有行。

階段 2：JOIN 子查詢 + 最左匹配（經典優化）

SELECT * FROM `table` AS t1
JOIN (
    SELECT ROUND(RAND() * (SELECT MAX(id) FROM `table`)) AS id
) AS t2 ON t1.id >= t2.id
ORDER BY t1.id LIMIT 5;

缺點：返回連續 5 行，非真正隨機；需執行 5 次取 1 行才均勻。

階段 3：完美隨機單行（含最小 ID 修正）

SELECT * FROM `table`
WHERE id >= (
    SELECT FLOOR(RAND() * ((SELECT MAX(id) FROM `table`) - (SELECT MIN(id) FROM `table`)) + (SELECT MIN(id) FROM `table`))
)
ORDER BY id LIMIT 1;

階段 4：JOIN 版完美隨機（效能最佳）

SELECT * FROM `table` AS t1
JOIN (
    SELECT ROUND(RAND() * ((SELECT MAX(id) FROM `table`) - (SELECT MIN(id) FROM `table`)) + (SELECT MIN(id) FROM `table`)) AS id
) AS t2 ON t1.id >= t2.id
ORDER BY t1.id LIMIT 1;

實測效能對比（15 萬行測試表）

查詢方式	執行 10 次總耗時	平均單次
ORDER BY RAND() LIMIT 1	~5 秒	500 ms
WHERE id >= (SELECT FLOOR(MAX*RAND())) LIMIT 1	~5 秒	500 ms
完美隨機子查詢版	1.47 秒	147 ms
JOIN 版完美隨機	0.15 秒	15 ms

多行隨機抽樣最佳實踐

1. 呼叫上述 JOIN 版單行查詢 N 次（應用層循環），收集唯一 ID 集合
2. 或使用 SELECT id FROM table ORDER BY RAND() LIMIT N 只取 ID（較輕），再 WHERE id IN (...) 回表
3. 極大表（億級）考慮：預計算隨機 ID 範圍、系統表抽樣、或應用層維護隨機樣本表

核心原理總結

• ORDER BY RAND() 觸發全表掃描 + 檔案排序 → O(N log N)
• 利用主鍵索引範圍查詢 → O(log N) 定位 + 少量掃描
• JOIN 讓子查詢只執行一次，避免相關子查詢重複計算
• 需 MySQL 4.1+ 支援子查詢

適用條件與限制

• 表必須有自增整數主鍵（或可排序唯一鍵）
• ID 分布相對均勻（大量刪除後建議 OPTIMIZE TABLE 或重建索引）
• 若需嚴格均勻分布且 ID 空洞極大，考慮維護一張 sample_ids 映射表