Pregunta

Por ejemplo cual es mejor:

select * from t1, t2 where t1.country='US' and t2.country=t1.country and t1.id=t2.id

o

select * from t1, t2 where t1.country'US' and t2.country='US' and t1.id=t2.id

mejor ya que en menos trabajo para la base de datos, resultados más rápidos.

Nota: Sybase, y hay un índice en ambas tablas de country+id.

¿Fue útil?

Solución

Tuve una situación similar a esta y esta fue la solución a la que recurrí:

Seleccione * de T1 Inner Unión T2 en T1.id = T2.ID y T1.country = T2.Country y T1.country = 'Us'

Noté que mi consulta se ejecutó más rápido en este escenario.Supuse que unirse a la constante ahorró tiempo al motor porque la cláusula WHERE se ejecutará al final.Unirse y luego filtrar por 'EE.UU.' significa que aun así extrajo todos los demás países de su tabla y luego tuvo que filtrar los que deseaba.Este método extrae menos registros al final, porque solo encontrará registros de EE. UU.

Otros consejos

No creo que haya una respuesta global a tu pregunta.Depende de la consulta específica.Tendría que comparar los planes de ejecución de las dos consultas para ver si existen diferencias significativas.

Personalmente prefiero la primera forma:

seleccione * de t1, t2 donde t1.country='US' y t2.country=t1.country y t1.id=t2.id

porque si quiero cambiar el literal solo se necesita un cambio.

Hay muchos factores en juego aquí que usted ha omitido.¿Qué tipo de base de datos es?¿Están indexadas esas tablas?¿Cómo se indexan?¿Qué tan grandes son esas mesas?

(¡La optimización prematura es la fuente de todos los males!)

Podría ser que si "t1.id" y "t2.id" están indexados, el motor de la base de datos los una en función de esos campos y luego usa el resto de la cláusula WHERE para filtrar filas.

Podrían ser tablas indexadas pero increíblemente pequeñas, y ambas caben en una página de memoria.En cuyo caso, el motor de la base de datos podría simplemente realizar un análisis completo de ambos en lugar de molestarse en cargar el índice.

En realidad, no lo sabes hasta que lo intentas.

La respuesta correcta probablemente dependa de su motor SQL.Para MS SQL Server, el primer enfoque es claramente el mejor porque el optimizador estadístico recibe una pista adicional que puede ayudarle a encontrar una ruta de resolución mejor (más óptima).

Creo que depende de la biblioteca y del motor de base de datos.Cada uno ejecutará el SQL de manera diferente y no se sabe cuál se optimizará.

Me inclinaría por incluir su constante en el código solo una vez.Puede haber una ventaja de rendimiento de una forma u otra, pero probablemente sea tan pequeña que la ventaja de mantenimiento de un solo parámetro la supera.

Si alguna vez desea hacer la consulta más general, tal vez sustituyendo un parámetro por el país de destino, entonces usaría su primer ejemplo, ya que solo requiere un cambio.Así habrá menos preocupación por equivocarse en el futuro.

Sospecho que esto dependerá de las tablas, los datos y los metadatos.Espero poder encontrar ejemplos que muestren resultados en ambos sentidos: ¡punto de referencia!

Las expresiones deberían ser equivalentes a cualquier optimizador decente, pero depende de qué base de datos esté utilizando y qué índices estén definidos en su tabla.

Sugeriría utilizar la función EXPLAIN para determinar cuál de las expresiones es la más óptima.

Creo que un SQL mejor sería:

Seleccione * de T1, t2 donde t1.id = t2.id y t1.country = 'nosotros'

No es necesario utilizar la segunda comparación con "EE. UU." a menos que sea posible que el país en t2 sea diferente de t1 para la misma identificación.

En lugar de utilizar una combinación interna implícita, uniría explícitamente las tablas.

Dado que desea que tanto los campos de identificación como los campos de país sean iguales, y mencionó que ambos están indexados (supongo que en el mismo índice), incluiría ambas columnas en la combinación para que pueda utilizar una búsqueda de índice. en lugar de un escaneo.Finalmente, agregue su cláusula donde.

SELECT *
  FROM t1
  JOIN t2 ON t1.id = t2.id AND t1.country = t2.country
 WHERE t1.country = 'US'

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top