2010-08-30 2 views
2

Я нашел себя в довольно рассоле. У меня есть таблицы только из одного столбца (списки ограничений или включения), которые являются более или менее varchar (25), но дело в том, что у меня не будет времени их индексировать, прежде чем использовать их в основном запросе и, в зависимости от того, насколько это важно, Я не знаю, сколько строк в каждой таблице. Базовая таблица в основе всего этого - около 1,4 миллиона строк и около 50 столбцов.Старый IN vs. Exists против Left Join (где ___ Is Is Is Null); Производительность

Мои предположения таковы:

В shouln't использоваться в случаях с большим количеством значений (строк) возвращается, потому что он выглядит, хотя значения серийно, не так ли? (ВО на вложенный запрос не передаются значения непосредственно)

присоединяется (внутренний для включения и влево и проверка на Nulls, когда подавление) являются лучшими для больших наборов данных (более 1k строк или так Маха к)

EXISTS всегда заботился обо мне, потому что он, кажется, делает подзапрос для каждой строки (все 1,4 миллиона? Yikes.)

Моя кишка говорит, если возможно получить счет таблицы супрессий и использовать либо IN (для sub 1k строки) и INNER/LEFT Join (для таблиц подавления выше 1k строк). Примечание. Поле, в которое я буду подавлять, будет индексом в большой базовой таблице, но таблица supression не будет. Мысли?

Заранее благодарим за любые замечания и/или советы.

ответ

6

Предполагая, что TSQL означает SQL Server, have you seen this link regarding a comparison of NOT IN, NOT EXISTS, and LEFT JOIN IS NULL? Таким образом, до тех пор, как столбцы сравниваемых не может быть NULL, NOT IN и NOT EXISTS являются более эффективными, чем LEFT JOIN/IS NULL ...

что-то, чтобы иметь в виду, о разнице между IN и EXISTS - EXISTS является логическим оператором, возвращает true при первом выполнении критериев. Хотя вы видите коррелированный подзапрос в синтаксисе, EXISTS выполнил лучше, чем IN ...

Кроме того, IN и EXISTS проверяют только наличие сравнения значений. Это означает, что нет дублирования записей, которые вы находите, когда JOINING ...

Это действительно зависит, поэтому, если вы действительно хотите найти то, что лучше всего выполнить, вам придется протестировать & сравнить то, что делают планы запросов. ..

+0

+1 Хорошая ссылка с хорошими показателями, чтобы поддержать заключение. – Thomas

+0

@Thomas: thx, напоминает мне, чтобы подтолкнуть Quassnoi на адрес, который лучше всего, когда столбцы могут быть пустыми ... –

0

Не имеет значения, какой метод вы используете, если в таблице, на которой вы применяете фильтр или соединение, нет индекса, система выполнит сканирование таблицы.

RE: Exists

Это не обязательно так, что система будет делать подзапрос для всех 1,4 миллиона строк. SQL Server достаточно умен, чтобы выполнять внутренний запрос Exists, а затем оценивать его по основному запросу. В некоторых случаях Exists может выполнять равную или лучше, чем Join.

Смежные вопросы