SQL - JOIN против производительности IN, когда IN - это фактический список значений (вместо запроса)

Question

Я видел вопросы, довольно похожие на этот, но они не совсем соответствуют тому, что я хочу.Допустим, у нас есть таблица, полная данных о магазинах:

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, поэтому не нужно беспокоиться об этом времени установки.Просто хочу сравнить фактические скорости обработки и / или планы запросов для двух операторов выше.Я бы подумал, что второе будет быстрее, но если список очень длинный, мне интересно, будет ли он медленнее.Какие-нибудь мысли?Бонусные баллы за ссылки на ответы!

Кроме того, если вы думаете, что ответ меняется, когда мы СОЕДИНЯЕМ больше таблиц (для других столбцов), по сравнению с добавлением большего числа IN-списков с AND, то вы можете свободно расширять анализ.

Answer 1

Ответ на ваш вопрос заключается в том, что вам нужно попробовать его: ваши данные, ваша система.

В целом, я ожидаю, что эти два будут иметь сопоставимую производительность выполнения. Для фиксированного списка SQL Server должен выполнять поиск по индексу.

Оптимизатор должен быть достаточно умен, чтобы делать то же самое с дополнительной таблицей.

Конечно, по мере того, как «список» увеличивается, SQL Server уравновешивает накладные расходы, связанные с перенаправлением через индекс, на простое чтение таблицы и сравнение значений. Таким образом, производительность и планы всегда должны быть проверены.