SQL JOIN против производительности?

У меня есть случай, когда использование JOIN или IN даст мне правильные результаты ... Какой тип обычно имеет лучшую производительность и почему? Насколько это зависит от того, на каком сервере базы данных вы работаете? (К сведению, я использую MSSQL)

Вообще говоря, INи JOINэто разные запросы, которые могут давать разные результаты.

SELECT  a.*
FROM    a
JOIN    b
ON      a.col = b.col

это не то же самое, что

SELECT  a.*
FROM    a
WHERE   col IN
        (
        SELECT  col
        FROM    b
        )

, если b.colне уникален.

Однако это синоним первого запроса:

SELECT  a.*
FROM    a
JOIN    (
        SELECT  DISTINCT col
        FROM    b
        )
ON      b.col = a.col

Если объединяющий столбец UNIQUEпомечен и помечен как таковой, оба этих запроса дают один и тот же план в SQL Server.

Если это не так, то INбыстрее, чем JOINна DISTINCT.

Смотрите эту статью в моем блоге для деталей производительности:

• INvs. JOINvs.EXISTS

Забавно, что вы упомянули, что я сделал пост в блоге на эту тему.

См. Oracle против MySQL против SQL Server: агрегация против объединений

Короткий ответ: вы должны проверить это, и отдельные базы данных сильно различаются.

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

Как общее практическое правило, я думаю, что если у вас есть индексы в столбцах внешнего ключа и если вы используете только (или в основном) условия INNER JOIN, то JOIN будет немного быстрее.

Но как только вы начнете использовать OUTER JOIN, или если вам не хватает индексов внешнего ключа, IN может быть быстрее.

Марк

Интересная статья о логических различиях: SQL Server: JOIN против IN против EXISTS - логическое различие

Я вполне уверен, что при условии сохранения отношений и индексов соединение будет работать лучше в целом (больше усилий уходит на работу с этой операцией, чем с другими). Если вы думаете об этом концептуально, то разница между 2 запросами и 1 запросом.

Вам нужно подключить его к Query Analyzer, попробовать и увидеть разницу. Также посмотрите на План выполнения запросов и постарайтесь свести к минимуму количество шагов.

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

Поэтому, если вас интересуют только значения из таблицы a, вы можете использовать этот запрос:

SELECT  a.*
FROM    a
WHERE   EXISTS (
    SELECT  *
    FROM    b
    WHERE   b.col = a.col
    )

Разница может быть огромной, если col не проиндексирован, потому что БД не нужно находить все записи в b, которые имеют одинаковое значение в col, он должен найти только самую первую. Если на b.col нет индекса, а при просмотре таблицы ba может быть много записей, это может быть следствием. Для IN или JOIN это будет полное сканирование таблицы, для EXISTS это будет только частичное сканирование таблицы (до тех пор, пока не будет найдена первая соответствующая запись).

Если в b много записей с одинаковым значением col, вы также потратите много памяти на чтение всех этих записей во временное пространство, просто чтобы убедиться, что ваше условие удовлетворено. С существующим этого обычно можно избежать.

Я часто находил EXISTS быстрее, чем IN, даже если есть индекс. Это зависит от системы баз данных (оптимизатора), данных и, что не менее важно, от типа используемого индекса.

Реализация каждой базы данных, но вы, вероятно, можете догадаться, что все они решают общие проблемы более или менее одинаково. Если вы используете MSSQL, взгляните на сгенерированный план выполнения. Вы можете сделать это, включив профилировщик и планы выполнения. Это даст вам текстовую версию при запуске команды.

Я не уверен, какую версию MSSQL вы используете, но вы можете получить графическую версию в SQL Server 2000 в анализаторе запросов. Я уверен, что эта функция скрывается где-то в SQL Server Studio Manager в более поздних версиях.

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

Оптимизатор должен быть достаточно умен, чтобы дать одинаковый результат в любом случае для обычных запросов. Проверьте план выполнения, и они должны дать вам то же самое. Если они этого не делают, я обычно считаю, что JOIN быстрее. Тем не менее, все системы разные, поэтому вы должны быть уверены, что профиль вашего кода должен быть профилирован.