IN vs UNION ALL：百萬級代理查詢的 SARG 性能實測

爭論焦點：IN 是否符合 SARG 標準？

早期觀點： IN 不符合 SARG（Search ARGument），導致全表掃描。

現代事實： SQL Server 2005+ 優化器可將 IN 轉為多個 OR 或 UNION ALL 邏輯，充分利用索引尋找。

實驗場景

• 表：member（百萬級），proxyID 有非聚集索引。
• 需求：查詢 30 個指定代理的信息。

方案一：IN 列表

SELECT ... FROM member WHERE proxyID IN ('ID1','ID2',...,'ID30');

方案二：UNION ALL 串聯

SELECT ... FROM member WHERE proxyID = 'ID1'
UNION ALL
SELECT ... FROM member WHERE proxyID = 'ID2'
...

執行計劃對比

• IN 方案： 單一 Index Seek 配合 IN 範圍尋找，邏輯極簡，編譯耗時極低。
• UNION ALL 方案： 30 個獨立 Index Seek + Concatenation，計劃極長，編譯/優化開銷大，計劃緩存膨脹。

性能結論

最佳實踐

1. 優先使用 IN / = ANY： 代碼簡潔、優化器友好、計劃復用率高。
2. 超大列表（> 1000）考慮臨時表/表值參數： 避免編譯超時與計劃膨脹。
3. UNION ALL 適用場景： 不同來源、不同條件、需保留重複行的異構合併。
4. 參數化查詢： 搭配 sp_executesql 或 ORM 參數化，復用計劃。

結語

IN 早已不是性能殺手。理解 SARG 現代定義、信任優化器、善用參數化，才是高性能 SQL 的正道。