Блог

Главная - Вопросы по программированию - SQL-СОЕДИНЕНИЕ по сравнению С производительностью, КОГДА IN является фактическим списком значений (вместо запроса)

SQL-СОЕДИНЕНИЕ по сравнению С производительностью, КОГДА IN является фактическим списком значений (вместо запроса)

#sql #performance #tsql

#sql #Производительность #tsql

Вопрос:

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

 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, тогда не стесняйтесь расширять анализ.

Ответ №1:

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

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

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

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