MySQL OR、IN、UNION ALL 查詢效率實測：索引列 vs 非索引列、千萬數據量對比、最佳選擇策略

MySQL OR、IN、UNION ALL 查詢效率實測：索引列 vs 非索引列、千萬數據量對比、最佳選擇策略

網上流傳「UNION ALL 優於 OR/IN」，真相如何？本文通過 1000 萬數據實測，對比索引列與非索引列三種寫法的耗時、執行計劃（type/ref/rows），得出四條場景化選擇策略，打破迷信。

一、實測環境

-- UNION ALL
EXPLAIN SELECT * FROM BT WHERE ID=98 UNION ALL SELECT * FROM BT WHERE ID=85220 UNION ALL SELECT * FROM BT WHERE ID=9888589;
-- IN
EXPLAIN SELECT * FROM BT WHERE ID IN (98,85220,9888589);
-- OR
EXPLAIN SELECT * FROM BT WHERE ID=98 OR ID=85220 OR ID=9888589;

結果：耗時均 ~0.00s（EMS 工具顯示 93/94/93 ms，差異可忽略）。執行計劃：UNION ALL 走 ref（非唯一索引掃描），OR/IN 走 range（索引範圍掃描），ref 理論優於 range 但實測無感知。掃描行數均為 3。

三、非索引列（VName）查詢三值對比

四、綜合策略建議

不迷信 UNION ALL：需結合索引情況、數據分布、查詢複雜度綜合判斷。
索引列優先 UNION ALL：復雜查詢中 OR/IN 可能導致優化器放棄索引全表掃描，UNION ALL 能保證每分支走索引（ref）。
非索引列堅決用 OR/IN：全表掃描不可避免，UNION ALL 只會成倍增加掃描次數。
混合列（含索引+非索引）：推薦 OR/IN，除非索引列查詢極慢需拆分。多表 JOIN 時再結合連接方式、數據量分布、索引情況綜合決策。