Коррелированный запрос и производительность внутреннего соединения в SQL Server

Question

Допустим, вы хотите выбрать все строки из одной таблицы, которые имеют соответствующую строку в другой (данные в другой таблице не важны, важно только наличие соответствующей строки). Из того, что я знаю о DB2, этот своего рода запрос лучше выполняется, когда он написан как коррелированный запрос с предложением EXISTS, а не INNER JOIN. Это то же самое для SQL Server? Или это не имеет никакого значения?

Answer 1

Я только что выполнил тестовый запрос, и два оператора закончились с одинаковым планом выполнения. Конечно, для любого вопроса производительности я бы порекомендовал провести тестирование в вашей собственной среде; С SQL Server Management Studio это легко (или SQL Query Analyzer, если вы используете 2000). Просто введите оба оператора в окно запроса, выберите Запрос | Включить фактический план запроса. Затем запустите запрос. Перейдите на вкладку результатов, и вы сможете легко увидеть, какие планы существуют и какой из них стоил дороже.

Answer 2

Используйте объединение. Это может не сильно повлиять на производительность, если у вас маленькие таблицы, но если «внешняя» таблица очень велика, то для каждой строки потребуется выполнить подзапрос EXISTS. Если ваши таблицы проиндексированы по общим столбцам, тогда будет гораздо быстрее выполнить INNER JOIN. Кстати, если вы хотите найти все строки, которых нет во второй таблице, используйте LEFT JOIN и проверьте на NULL во второй таблице - это намного быстрее, чем использование EXISTS, когда у вас очень большие таблицы и индексы.

Answer 3

Странно: обычно для меня более естественно сначала написать их как коррелированный запрос, после чего я должен затем вернуться и повторно использовать фактор объединения, потому что по моему опыту оптимизатор сервера sql с большей вероятностью получит это верно.

Но не принимай меня слишком серьезно. Несмотря на то, что у меня здесь 26 тыс. Повторений и один из 2 текущих значков, относящихся к теме sql, я на самом деле немного младше с точки зрения знаний sql (все дело в объеме!;)); конечно я не администратор. На практике вам, конечно, нужно будет профилировать каждый метод, чтобы оценить его реальную производительность. Я бы ожидал , что оптимизатор распознает то, что вы просите, и обработает любой запрос оптимальным способом, но вы никогда не узнаете, пока не проверите.

Answer 4

Вероятно, лучшая производительность при соединении с производной таблицей. Существующие, вероятно, будут следующими (и могут быть быстрее). Худшая производительность была бы с подзапросом внутри выбора, поскольку он имел бы тенденцию запускаться строка за строкой вместо набора.

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

Answer 5

Как все отмечают, все сводится к оптимизатору. Я бы предложил написать его так, как вам кажется, более естественным, а затем убедиться, что оптимизатор может определить наиболее эффективный план запросов (собрать статистику, создать индекс и т. Д.) Оптимизатор SQL Server в целом довольно хорош, если вы предоставляете ему информацию, с которой он должен работать.