¿es mejor poner más lógica en su cláusula ON o solo debe tener el mínimo necesario?

Question

Dadas estas dos consultas:

Select t1.id, t2.companyName 
from table1 t1 
    INNER JOIN table2 t2 on t2.id = t1.fkId 
WHERE t2.aField <> 'C' 

O:

Select t1.id, t2.companyName 
from table1 t1 
    INNER JOIN table2 t2 on t2.id = t1.fkId and t2.aField <> 'C' 

¿Hay una diferencia demostrable entre los dos? Me parece que la cláusula "t2.aField <> 'C'" se ejecutará en cada fila en t2 que cumpla con los criterios de unión independientemente. ¿Soy incorrecto?

Actualización: Realicé un "Incluir plan de ejecución real" en SQL Server. Las dos consultas fueron idénticas.

Answer 1

Prefiero utilizar los criterios de combinación para explicar cómo se unen las tablas. Así que colocaría la cláusula adicional en la sección donde.

Espero (aunque no tengo estadísticas) que SQL Server sea lo suficientemente astuto como para encontrar el plan de consulta óptimo independientemente de la sintaxis que utilice.

SIN EMBARGO, si tiene índices que también tienen identificación y un campo en ellos, le sugiero que los coloque juntos en los criterios de unión interna.

Sería interesante ver el plan de consulta en estos 2 (o 3) escenarios, y ver qué pasa. Buena pregunta.

Answer 2

Hay una diferencia. Debe hacer un PLAN DE EXPLICACIÓN para los dos seleccionados y verlo en detalle.

En cuanto a una explicación simplista: La cláusula WHERE se ejecuta solo después de la unión de las dos tablas, por lo que se ejecuta para cada fila devuelta desde la unión y no necesariamente cada una de la tabla2.

Rendimiento sabio es el mejor para eliminar los resultados no deseados desde el principio por lo que debe haber menos filas para las uniones, donde las cláusulas u otras operaciones para hacer frente más adelante.

En el segundo ejemplo, hay 2 columnas que tienen que ser iguales para las filas que se unirán, por lo que generalmente dará resultados diferentes a la primera.

Answer 3

Prefiero la primera consulta. El servidor SQL usará el mejor tipo de combinación para su consulta en función de los índices que tenga, después de eso aplicará la cláusula WHERE. Pero puede ejecutar ambas consultas al mismo tiempo, ver los planes de ejecución, comparar y elegir el más rápido (optimizar también agregar índices).

Answer 4

Depende.

SELECT 
    t1.foo, 
    t2.bar 
FROM 
    table1 t1 
    LEFT JOIN table2 t2 ON t1.SomeId = t2.SomeId 
WHERE 
    t2.SomeValue IS NULL 

es diferente de

SELECT 
    t1.foo, 
    t2.bar 
FROM 
    table1 t1 
    LEFT JOIN table2 t2 ON t1.SomeId = t2.SomeId AND t2.SomeValue IS NULL 

Es diferente porque los primeros cruces con todos los registros de t2 que tienen NULL en t2.SomeValue y los de T1 que no se hace referencia en t2. Este último tacha solo los registros t2 que tienen NULL en t2.SomeValue.

Simplemente use la cláusula ON para la condición de unión y la cláusula WHERE para el filtro.

Answer 5

a menos que esté trabajando en una aplicación para un solo usuario o algo similar que crea una carga trivial, las únicas consideraciones que tienen sentido es cómo el servidor procesará su consulta.

Las respuestas que mencionan planes de consulta dan buenos consejos.

Además, establezca las estadísticas io para tener una idea de cuántas lecturas generará su consulta (me gusta especialmente la publicación de Azder).

Piense en cada servidor de base de datos como una bomba de datos desde el disco al cliente. Esa bomba funciona más rápido si solo realiza el IO necesario para realizar el trabajo. Si los datos están en caché, serán aún más rápidos. Pero no querrá leer más de lo que necesita del disco, lo que provocará que se eliminen los datos útiles de su caché sin una buena razón.

Answer 6

A menos que mover la condición de unión a la cláusula where cambie el significado de la consulta (como en el ejemplo de la combinación de la izquierda anterior), entonces no importa dónde los coloque. SQL los reorganizará y, siempre que sean equivalentes, obtendrá la misma consulta.

Habiendo dicho eso, creo que es más una cosa lógica/de legibilidad. Normalmente pongo todo lo que relaciona dos tablas en la combinación, y cualquier cosa que se filtre en el lugar.