SQL-當IN是實際值列表（而不是查詢）時，JOIN與IN的性能

Question

我見過與這個問題相當相似的問題，但是它們並不能完全滿足我的需求。 假設我們有一個充滿有關Stores數據的表：

Stores
(
     Store int,
     Address string,
     ... (20+ columns of data),
     ,PRIMARY KEY CLUSTERED (Store)
)

現在讓我們說這個表有數億行。 我想要有關這些商店中的100家的信息分布在整個表格中。 我還有這100家商店的另一張桌子：

MyStores
(
     Store int,
     PRIMARY KEY CLUSTERED (Store)
)

我想知道這兩個語句之間的性能差異：

SELECT a.*
FROM Stores a
JOIN MyStores b
     ON a.Store = b.Store

與

    SELECT *
    FROM Stores
    WHERE Store IN (12, 34, 56, ..., 99999)

 -- 100 stores in this list

這沒有使用動態SQL，並且我已經有了MyStores表，因此無需擔心安裝時間。 只想比較上面兩個語句的實際處理速度和/或查詢計划。 我認為第二個自然會更快，但是如果列表很長，我想知道它是否最終會變慢。 有什么想法嗎？ 獎勵積分，提供答案鏈接！

同樣，如果您認為我們加入更多表（對於其他列）時答案有所變化，與添加更多具有AND的IN列表相比，您可以隨時擴展分析。

Answer 1

問題的答案是您需要嘗試一下：數據，系統。

通常，我希望兩者具有可比的執行性能。 對於固定列表，SQL Server應該執行索引查找。

優化器應該足夠聰明，可以對輔助表執行相同的操作。

當然，隨着“列表”的增大，SQL Server正在平衡通過索引重定向到僅讀取表並比較值的開銷。 因此，應始終檢查性能和計划。