Condición dentro de JOIN o WHERE

¿Hay alguna diferencia (rendimiento, mejores prácticas, etc.) entre poner una condición en la cláusula JOIN frente a la cláusula WHERE?

Por ejemplo...

-- 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'

¿Cuál prefieres (y quizás por qué)?

El álgebra relacional permite la intercambiabilidad de los predicados en la WHEREcláusula y INNER JOIN, por lo tanto, incluso las INNER JOINconsultas con WHEREcláusulas pueden hacer que el optimizador reorganice los predicados para que puedan ser excluidos durante el JOINproceso.

Le recomiendo que escriba las consultas de la manera más legible posible.

A veces, esto incluye hacer lo INNER JOINrelativamente "incompleto" y poner algunos de los criterios WHEREsimplemente para hacer que las listas de criterios de filtrado sean más fáciles de mantener.

Por ejemplo, en lugar de:

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

Escribir:

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

Pero depende, por supuesto.

Para las uniones internas, realmente no he notado una diferencia (pero como con todos los ajustes de rendimiento, debe verificar su base de datos bajo sus condiciones).

Sin embargo, donde coloca la condición hace una gran diferencia si está utilizando uniones izquierdas o derechas. Por ejemplo, considere estas dos consultas:

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'

El primero le dará solo aquellos registros que tengan un pedido con fecha posterior al 15 de mayo de 2009, lo que convierte la unión izquierda en una unión interna.

El segundo dará esos registros más cualquier cliente sin pedidos. El conjunto de resultados es muy diferente dependiendo de dónde coloque la condición. (Seleccionar * es solo para fines de ejemplo, por supuesto, no debe usar esto en el código de producción).

La excepción a esto es cuando desea ver solo los registros en una tabla pero no en la otra. Luego usa la cláusula where para la condición, no la unión.

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

La mayoría de los productos RDBMS optimizarán ambas consultas de manera idéntica. En "SQL Performance Tuning" de Peter Gulutzan y Trudy Pelzer, probaron varias marcas de RDBMS y no encontraron diferencias de rendimiento.

Prefiero mantener las condiciones de unión separadas de las condiciones de restricción de consulta.

Si está utilizando a OUTER JOINveces es necesario poner condiciones en la cláusula de unión.

DONDE se filtrará después de que se haya producido la UNIÓN.

Filtre en JOIN para evitar que se agreguen filas durante el proceso de JOIN.

Prefiero JOIN para unir tablas / vistas completas y luego usar WHERE para presentar el predicado del conjunto resultante.

Se siente sintácticamente más limpio.

Normalmente veo un aumento en el rendimiento al filtrar en la unión. Especialmente si puede unirse en columnas indexadas para ambas tablas. Debería poder reducir las lecturas lógicas con la mayoría de las consultas haciendo esto también, que es, en un entorno de alto volumen, un indicador de rendimiento mucho mejor que el tiempo de ejecución.

Siempre me divierte un poco cuando alguien muestra su evaluación comparativa de SQL y ha ejecutado ambas versiones de un sproc 50,000 veces a la medianoche en el servidor de desarrollo y compara los tiempos promedio.

Poner la condición en la combinación me parece "semánticamente incorrecto", ya que no es para eso que están "unidas". Pero eso es muy cualitativo.

Problema adicional: si decide cambiar de una unión interna a, por ejemplo, una unión correcta, tener la condición dentro de la UNIÓN podría generar resultados inesperados.

Las uniones son más rápidas en mi opinión cuando tienes una mesa más grande. Realmente no es una gran diferencia, especialmente si se trata de una mesa más pequeña. Cuando supe por primera vez sobre las combinaciones, me dijeron que las condiciones en las combinaciones son como las condiciones de la cláusula where y que podría usarlas indistintamente si la cláusula where fuera específica sobre qué tabla hacer la condición.

Es mejor agregar la condición en la Unión. El rendimiento es más importante que la legibilidad. Para grandes conjuntos de datos, es importante.