Cual de estas consultas es mas rapida?

[RIVERMILLOS]

Código MySQL:

SELECT PXU.punto,C.ruta,PXU.idpropiedad,C.idcasas
               FROM propiedadesxusuarios PXU
               INNER JOIN manzanasxpropiedades MXP
               ON P.idpropiedad = MXP.idpropiedad
               INNER JOIN manzanas M
               ON M.idmanzana = MXP.idmanzana
               INNER JOIN casas C
               ON C.idcasas = PXU.idcasas
               WHERE M.idbarrio =468;
 
SELECT PXU.punto,C.ruta,P.idpropiedad,C.idcasas,P.centro
               FROM propiedades P
               INNER JOIN manzanasxpropiedades MXP
               ON P.idpropiedad = MXP.idpropiedad
               INNER JOIN manzanas M
               ON M.idmanzana = MXP.idmanzana
               INNER JOIN propiedadesxusuarios PXU
               ON PXU.idpropiedad=P.idpropiedad
               INNER JOIN casas C
               ON C.idcasas = PXU.idcasas
               WHERE M.idbarrio =468;
 

las dos consultas me traen datos que me sirven igual , pero la diferencia es que en la primera utilizo la PK de la tabla propiedades y la segunda la Fk de propiedadesxusuarios?


saludos

[Marvin]

Yo creo que esta es mas rapida:

Código Mysql:

SELECT punto,ruta,idpropiedad,idcasas
FROM propiedadesxusuarios 
    NATURAL JOIN manzanasxpropiedades 
    NATURAL JOIN manzanas
    NATURAL JOIN casas
WHERE idbarrio =468
 

Suerte!

[gnzsoloyo]

Según el manual de referencia:

El NATURAL [LEFT] JOIN de dos tablas se define semánticamente equivalente a un INNER JOIN o LEFT JOIN con una cláusula USING que nombra todas las columnas que existen en ambas tablas.

De las dos que propones, la primera:

Código MySQL:

SELECT PXU.punto,C.ruta,PXU.idpropiedad,C.idcasas
FROM propiedadesxusuarios PXU
               INNER JOIN manzanasxpropiedades MXP ON P.idpropiedad = MXP.idpropiedad
               INNER JOIN manzanas M ON M.idmanzana = MXP.idmanzana
               INNER JOIN casas C ON C.idcasas = PXU.idcasas
               WHERE M.idbarrio =468;
 

es la más rápida por dos razones básicas: 1) Usas una tabla menos, lo que implica menos accesos a disco para la lectura, y una tabla derivada menos, y 2) traes una columna menos, lo que implica que pueden entrar más registros por bloque de memoria usado en los datos leídos.

[RIVERMILLOS]

Muchas gracias por la respuesta, pero supugon que es recomendable usar mejor el NATURAL JOIN , esto mejora el performance?

saludos

[gnzsoloyo]

Es igual que usar INNER JOIN con USING en lugar de ON.

Código MySQL:

SELECT PXU.punto,C.ruta,PXU.idpropiedad,C.idcasas
FROM 
      propiedadesxusuarios PXU 
      INNER JOIN manzanasxpropiedades MXP USING(idpropiedad)
      INNER JOIN manzanas M USING(idmanzana)
      INNER JOIN casas C USING(idcasas)
WHERE M.idbarrio =468;
 

El parser ejecuta exactamente lo mismo.
La condición es que los campos relacionados tienen que tener el mismo nombre en ambas tablas, exactamente igual que en el NATURAL JOIN.

[RIVERMILLOS]

OK muchas gracias me gusta el USING se ve mas clara la consulta , pero en cuanto a redimiento no tienen relevancia?


saludos

[gnzsoloyo]

Nop. El parser las evalúa de la misma forma. por eso el manual habla de "semánticamente equivalente ".

[RIVERMILLOS]

Que pena ser tan molesto con esto pero estoy obsecionado con el rendimiento de mi aplicacion y la base de datos, y si a la segunda cosulta de las dos primeras, le agredo estos filtros?

Código MySQL:

WHERE P.idtipospropiedades=1 AND P.idestadopropiedad!=2 AND M.idbarrio =468
 

cambiaria en algo o seguiria siendo mas rapida la segunda?


saludos

[gnzsoloyo]

El WHERE no es optimizable por el parser. Se aplica sobre el resultado final y en definitiva sólo impacta en los datos efectivamente devueltos, lo que significa que lo único que hace es elegir cuáles devolverá, pero el proceso base sigue siendo el mismo.
Es por eso que yo muchas veces recalco que un factor fundamental es la selectividad de las relaciones: Mientras menos registros se obtengan de cada tabla invocada a causa de los INNER JOIN, más rápida será la consulta.
Aumentarle las condiciones del WHERE sólo tendría algún impacto si tienes índices definidos sobre el conjunto de datos, pero por otro lado, si la cardinalidad de los índices es muy alta, tendrán efecto negativo sobre las inserciones/actualziaciones...