Que consulta de las 2 es mejor?

albertius · #1 (**permalink**) 28/10/2010, 09:43

Hola a todos.
Estas dos consultas generan el mismo resultado, una hace tres subconsultas y la otra utiliza LEFT JOIN dos veces y hace una subconsulta.

Cual de las dos es mas eficaz o gasta menos recursos??

1.
$_consulta = sprintf("SELECT emp.value AS empresa, nom.value AS nombre, factura.id_fac, factura.print_fac, factura.num_fac, factura.fecha_creacion_fac, factura.estado_fac, (SELECT sum(pvp_factura_det) FROM conta_detalle_factura WHERE id_factura_det=factura.id_fac) AS pvp FROM conta_facturas AS factura LEFT JOIN profile_values AS emp ON emp.fid=%s && emp.uid=factura.uid_fac LEFT JOIN profile_values AS nom ON nom.fid=%s && nom.uid=factura.uid_fac WHERE factura.uid_fac>1 ".$where." ORDER BY ".$orderBy, $fid,$fnom);

2.
$_consulta = sprintf("SELECT factura.id_fac, factura.print_fac, factura.num_fac, factura.fecha_creacion_fac, factura.estado_fac, (SELECT sum(pvp_factura_det) FROM conta_detalle_factura WHERE id_factura_det=factura.id_fac) AS pvp, (SELECT value FROM profile_values WHERE profile_values.fid=%s && profile_values.uid=factura.uid_fac) AS empresa, (SELECT value FROM profile_values WHERE profile_values.fid=%s && profile_values.uid=factura.uid_fac) AS nombre FROM conta_facturas AS factura WHERE factura.uid_fac>1 ".$where." ORDER BY ".$orderBy, $fid, $fnom);

Un saludo

Vun · #2 (**permalink**) 28/10/2010, 09:48

¿Te fijaste en cuanto tarda mysql en ejecutarlas? igual si no tienes muchos datos no es muy relevante pero bueno... También podrias usar EXPLAIN y poner aqui los resultados.

Yo no sabría decirte ahora mismo, pero juraría que a MENOS selects y mejores indices tengas, menos trabajo para mysql... (esta afirmación es exageradamente simplona...)

leonardo_josue · #3 (**permalink**) 28/10/2010, 15:19

En lo particular he comprobado que utilizar JOIN en lugar de subconsultas tiene mejor desempeño, sobre todo cuando se trata de tablas con muchos registros. El tiempo de ejecución se disminuye considerablemente. Como comenta vum, es cuestión de que revises cuál de las consultas se ejecuta más rápidamente y que revises los resultados del EXPLAIN para tratar de determinar el performanse de las consultas

Saludos
Leo.

albertius · #4 (**permalink**) 28/10/2010, 15:39

Gracias, voy a hacer un test, pero igualmente no trabaja con demasiados registros.

gnzsoloyo · #5 (**permalink**) 28/10/2010, 16:08

En ese caso es posible que no puedas ver la diferencia de performance entre las consultas. Estas se empiezan a notar recién cuando se trabaja con decenas o centenares de miles de registros o más. Con algunos cientos, no se ve demasiado cambio.

albertius · #6 (**permalink**) 28/10/2010, 16:13

Muy bien... pues ya me gustaria notar la diferencia, puesto que la consulta es sobre la tabla de mis clientes..Imagina "decenas o centenares de miles" de clientes.

Un saludo

nomafeito · #7 (**permalink**) 29/10/2010, 06:01

Esto es lo que hago para calcular la eficiencia de una consulta:

Código PHP:

     $crono2=0;
    $crono=microtime();
   CONSULTA MYSQL
    $crono2=microtime();
    $crono2=$crono2-$crono;
echo $crono2;

Compara las consultas, evidentemente cuanto menos tiempo es el más eficaz.

gnzsoloyo · #8 (**permalink**) 29/10/2010, 07:31

Muy lindo, pero no consideras el overhead producido por transacciones, network, locks, carga de procesador, uso de memoria, etc.
Solamente estas midiendo el tiempo que tarda entre enviar desde el script PHP la sentencia al servidor y retornar el resultado; pero ese tiempo está afectado por muchos factores que no necesariamente son producidos por la sentencia de SQL.
Cosas a tener en cuenta:
- Los DBMS trabajan en forma estadística y poseen algorimos que permiten cambiar el plan de ejecución de una consulta según los resultados de esas estadísticas. Asi, es perfectamente posible que dos ejecuciones de la misma sentencia en momentos diferentes del tiempo tarden diferente tiempo, aún con el mismo conjunto de datos.
- La implementación de índices puede afectar la performance de la consulta, aún sin necesidad de reescribirla. Estos son usados internamente por MySQL, por lo que en realidad son invisibles para el programador.
- El mayor impacto en la performance es producto del hardware, por lo que cambios en él, afectan el tiempo de ejecución más que la sintaxis de la misma. Ampliar la memoria RAM o los discos usados tiene a veces mayor efecto que reescribir una consulta.
- La forma de configuración del servidor también puede afectar el tiempo de respuesta. Cambiar un servidor de 150 conexiones simultáneas a 500, y de compartido a dedicado, tiene un impacto directo en la performance.
- El número de usuarios concurrentes es otro factor sumamente importante a la hora de realizar consultas. Muchos usuarios implican el uso de mucha memoria de consultas y muchas transacciones concurrentes.
- Otros (muchos) motivos...

Todas estas cosas son invisibles para el PHP y sin embargo esa forma de "calcular" la performance no las puede tener en cuenta, porque no tienes acceso a toda esa información...

A nivel de la consulta en si, la mejor o peor performance que se puede obtener es producto de calcular el CC (costo de consulta), para lo cual deben hacerse ciertos cálculos partiendo de la base que mientras menos acceso a disco requiere para obtener la información, mejor es la performance de la consulta en sí. Esto se hace con ciertos cálculos que normalmente aparecen en la documentación especializada, o bien en los apuntes de los cursos de bases de datos.

bavarol · #9 (**permalink**) 31/10/2010, 10:35

Con JOIN(usado de manera cabal) suele reducirse el tiempo por lo que se.

albertius · #10 (**permalink**) 31/10/2010, 12:43

Ok..clarisimo todo.

gnzsoloyo, todo lo que dices es muy lógico, pero si usamos la operación de nomafeito en una función con consultas, una SELECT otra JOIN y así 200 o 10000 veces, en la misma máquina, por estadística obtendriamos una respuesta creo acertada.

Saludos y gracias.

gnzsoloyo · #11 (**permalink**) 31/10/2010, 12:49

Aún así, piensa que no podrías establecer cuál es la parte del tiempo que corresponde a la eficiencia de la sintaxis de la sentencia...
Yo creo que sigue siendo mejor usar EXPLAIN y analizar mejor el contenido de las tablas para lograr una sintaxis eficiente.
El tiempo de procesos en servidor tomado desde PHP me parece demasiado impreciso.

Por caso, recientemente reconfiguramos un servidor local porque ciertas consultas se había vuelto lentas cuando una de las tablas más grandes superaba los 53 millones de registros (alrededor de 38 segundos por consulta en un rango de 30 días).
Lo único que hicimos fue cambiar de Developer Machine a Servidor Dedicado y poner toda la base en un disco independiente sólo para este servidor, y el tiempo de consulta se redujo a 9 segundos para el mismo rango de datos... Sin modificar una línea de la consulta.

Por eso digo que el hardware y la configuración tienen un gran impacto en la performance.

albertius · #12 (**permalink**) 31/10/2010, 12:59

Ok, entiendo.

Otra cosa relacionada...
Con el uso de subconsultas, se puede por ejemplo en una misma consulta actualizar un registro de un tabla y con la subconsulta actualizar uno de otra tabla??
De ser afirmativo, Puede ser true la consulta principal y false la subconsulta???
Yo creo que si peta una, petan todas pero lo pregunto porque muchas veces utilizo transacciones en innoDB para asegurar que se cumplan todas las consultas.

gnzsoloyo · #13 (**permalink**) 31/10/2010, 17:13

Cita:

Con el uso de subconsultas, se puede por ejemplo en una misma consulta actualizar un registro de un tabla y con la subconsulta actualizar uno de otra tabla??

No. El hecho de que estés haciendo una subconsulta no quiere decir que hagas dos cosas distintas. Una subconsula lo que hace es generar una tabla derivada de donde otra consulta toma los datos. Pero no significa que estés ejecutando dos sentencias separadas, sino que ambas integran una sola unidad final.
Lo que tu quieres hacer se hace por medio de stored procedures, no de SELECTS. Además, ten en cuenta que un INSERT (que sería el caso) no se admite como fuente de datos sino como destino de datos, lo que quiere decir que una subconsulta sólo puede ser un SELECT y jamás un INSERT.

Cita:

De ser afirmativo, Puede ser true la consulta principal y false la subconsulta???

¿Por qué no? Es lo más habitual. Es el caso de

Código MySQL:

Ver originalSELECT a, b, c
FROM t
WHERE a IN(SELECT ... FROM...)

donde el IN resultase falso.
El problema de tales situaciones es que el resultado final suele ser NULL (conjunto vacío de registros).
El tema depende exclusivamente de lo que desees obtener y para qué lo quieres usar así.

Cita:

Yo creo que si peta una, petan todas pero lo pregunto porque muchas veces utilizo transacciones en innoDB para asegurar que se cumplan todas las consultas.

El cumplimiento de la lógica de las consultas tiene relación con la lógica que estás aplicando y para qué.
Yo tengo en algunas aplicaciones consultas cuyo valor de respuesta es crecisamente "FALSE", porque esa es la condición que yo busco, y en algunas de ellas estoy haciendo JOINS sobre tres tablas...

Como te dije, todo depende de lo que estés queriendo conseguir, no de las propiedades del SQL...

albertius · #14 (**permalink**) 31/10/2010, 17:19

Clarisimo...muchas gracias.

bavarol · #15 (**permalink**) 01/11/2010, 04:08

Cita:

Iniciado por albertius

Ok, entiendo.

Otra cosa relacionada...
Con el uso de subconsultas, se puede por ejemplo en una misma consulta actualizar un registro de un tabla y con la subconsulta actualizar uno de otra tabla??
De ser afirmativo, Puede ser true la consulta principal y false la subconsulta???
Yo creo que si peta una, petan todas pero lo pregunto porque muchas veces utilizo transacciones en innoDB para asegurar que se cumplan todas las consultas.

A ver, de forma generica unos consejillos, JOIN explicito antes que el join implicito "=" (siempre que puedas y estes ducho en la materia y puedas comprenderlo tanto tu como tus companieros) y otra es usar cursores en la medida de lo posible, eso es lo que sin tener que hacer mucho mas, reduce la "performance".