Условие в СОЕДИНЕНИИ или ГДЕ

Есть ли разница (производительность, лучшие практики и т. Д.) Между помещением условия в предложение JOIN и предложением WHERE?

Например...

-- Condition in JOIN
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND CUS.FirstName = 'John'

-- Condition in WHERE
SELECT *
FROM dbo.Customers AS CUS
INNER JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE CUS.FirstName = 'John'

Что вы предпочитаете (и, возможно, почему)?

Реляционная алгебра допускает взаимозаменяемость предикатов в WHEREпредложении и INNER JOIN, таким образом, даже INNER JOINзапросы с WHEREпредложениями могут иметь предикаты, переупорядоченные оптимизатором, чтобы они уже могли быть исключены во время JOINпроцесса.

Я рекомендую вам писать запросы наиболее читабельным способом.

Иногда это включает в себя создание INNER JOINотносительно «неполных» и включение некоторых критериев WHEREпросто для того, чтобы сделать списки критериев фильтрации более легкими в обслуживании.

Например, вместо:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
    AND c.State = 'NY'
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
    AND a.Status = 1

Напишите:

SELECT *
FROM Customers c
INNER JOIN CustomerAccounts ca
    ON ca.CustomerID = c.CustomerID
INNER JOIN Accounts a
    ON ca.AccountID = a.AccountID
WHERE c.State = 'NY'
    AND a.Status = 1

Но это зависит, конечно.

Для внутренних объединений я не заметил заметной разницы (но, как и во всех настройках производительности, вы должны проверить свою базу данных в ваших условиях).

Однако, где вы ставите условие имеет огромное значение, если вы используете левое или правое соединение. Например, рассмотрим эти два запроса:

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderDate >'20090515'

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
AND ORD.OrderDate >'20090515'

Первый даст вам только те записи, чей заказ датирован позднее 15 мая 2009 года, и, таким образом, преобразование левого объединения во внутреннее объединение.

Второй даст эти записи плюс любые клиенты без заказов. Набор результатов сильно отличается в зависимости от того, где вы поставили условие. (Выберите * только для примера, конечно, вы не должны использовать это в рабочем коде.)

Исключением является случай, когда вы хотите видеть только записи в одной таблице, но не в другой. Затем вы используете условие where для условия, а не для соединения.

SELECT *
FROM dbo.Customers AS CUS 
LEFT JOIN dbo.Orders AS ORD 
ON CUS.CustomerID = ORD.CustomerID
WHERE ORD.OrderID is null

Большинство продуктов RDBMS оптимизируют оба запроса одинаково. В «Настройка производительности SQL» Питера Гулутзана и Труди Пельцер они протестировали несколько брендов RDBMS и не обнаружили различий в производительности.

Я предпочитаю хранить условия соединения отдельно от условий ограничения запросов.

Если вы используете OUTER JOINиногда, необходимо поместить условия в предложение join.

WHERE будет фильтровать после того, как произошло СОЕДИНЕНИЕ.

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

Я предпочитаю, чтобы JOIN объединял полные таблицы / представления, а затем использовал WHERE для представления предиката результирующего набора.

Это чувствует себя синтаксически чище.

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

Я всегда слегка удивлен, когда кто-то показывает свой сравнительный анализ SQL, и он выполнил обе версии sproc 50000 раз в полночь на сервере разработчиков и сравнил среднее время.

Помещение условия в объединение кажется мне «семантически неправильным», поскольку это не то, для чего «соединения» являются «для». Но это очень качественно.

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

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

Лучше добавить условие в Join. Производительность важнее, чем удобочитаемость. Для больших наборов данных это имеет значение.