Query super lento

[Fabu_dina]

NECESITO MEJORAR ESTE QUERY ALGUIEN ME PUEDE APOYAR

Código SQL:

SELECT mv.mov_ide AS ide,mv.mov_fecha1 AS fecha1,mv.mov_folio AS folio,mv.mov_cuenta_origen AS cta_origen,mv.mov_observacion AS observacion, 
mb.mov_concepto AS concepto, mv.mov_abonos AS abono,mv.clave_confirma AS confirma,mv.mov_cliente AS cliente,mv.mov_region1 AS region1, 
c.cuenta_clabe AS clabe,cat.cat_nombre AS categoria 
FROM movimientos_clientes mv 
JOIN cuenta c ON c.cuenta_id = mv.mov_cuenta 
JOIN usuario u ON u.usuario_id=mv.mov_usuario_solicita  
JOIN cat_mov CAT ON cat.cat_id=mv.mov_producto1  
JOIN movimientos_bancarios mb ON mb.mov_id = mv.mov_mov  
WHERE mv.mov_1='AUTO' AND mov_mov<>0 AND clave_confirma<>'N/A' AND mv.mov_factura='0' AND  (mv.mov_usuario=101 OR mv.mov_operador=1)
 

[leonardo_josue]

Hola Fabu_dina:

Como tal, no hay muchas cosas mejorar en tu consulta, pero sí hay varias cosas que tienes que revisar

1. No nos dices en tu post qué indices tienes definidos en cada una de tus tablas. Verifica bien que tengas definidas llaves primarias y/o FK según corresponda en las consultas y utiliza EXPLAIN para obtener información adicional al rendimiento de la consulta.

2. ¿realmente necesitas todas las tablas que estás utilizando en los JOIN's? por ejemplo, la tabla usuario no veo que la utilices para nada... no haces ningún SELECT a algún campo ni la utilizas para filtrar información.

3. ¿de qué tipo de datos son tus campos?, por ejemplo, el campo MOV_FACTURA ¿es de tipo numérico o caracter? si es de tipo numérico, entonces no pongas comillas en la condición ya que estás obligando a hacer una conversión implícita.

Código:

mv.mov_factura='0'

Saludos
Leo.

[Fabu_dina]

esto es lo que me dice el explain

Código MySQL:

1   SIMPLE  mv  ref movi,confirma,compras_rep,clientes,autorizar,concilia,disparado,solicitudes,void,sol_operador   void    48  const   165959  Using where
1   SIMPLE  CAT eq_ref  PRIMARY PRIMARY 4   concilia.mv.mov_producto1   1   Using where
1   SIMPLE  u   eq_ref  PRIMARY PRIMARY 4   concilia.mv.mov_usuario_solicita    1   Using where; Using index
1   SIMPLE  mb  eq_ref  PRIMARY PRIMARY 4   concilia.mv.mov_mov 1   
1   SIMPLE  c   eq_ref  PRIMARY,engresos,busqueda_activa    PRIMARY 4   concilia.mv.mov_cuenta  1
 

[ptilotta]

Hola

Coincido con Leonardo en que no hay mucho por optimizar a simple vista en tu SQL, pero dudo que todas esas uniones sean por Indices.

Tienes que hacer mas que nada un trabajo exhaustivo en tus tablas , revisando que tal tienes los indices, y si los datos que se supone que estas uniendo, son del mismo tipo y la misma longitud.

Si una consulta de ese tipo tarda, tienes que primero ver cuantos registros devuelve, porque si devuelve millones de registros (es una metafora) , por mas que tengas los indices perfectos, siempre demorará mucho.

He hecho consultas kilométricas perfectamente diseñadas en tablas perfectamente diseñadas que demoraban horas y horas en ejecutarse, porque leían millones de registros para llenar un Cubo.

A simple vista no podemos saber si es OPTIMIZABLE o no.. porque desconocemos tus tablas.

Saludos

[Libras]

Iniciado por ptilotta

Hola


Si una consulta de ese tipo tarda, tienes que primero ver cuantos registros devuelve, porque si devuelve millones de registros (es una metafora) , por mas que tengas los indices perfectos, siempre demorará mucho.

He hecho consultas kilométricas perfectamente diseñadas en tablas perfectamente diseñadas que demoraban horas y horas en ejecutarse, porque leían millones de registros para llenar un Cubo.

consultas de millones de registros en horas? con tablas perfectamente diseñadas y queriess perfectos? C'mon, yo he realizado consultas con calculos acumulativos sobre millones de registros y me devolvian la informacion en 5 minutos, asi que te puedo decir que tus queries no eran perfectos ;)

[ptilotta]

Iniciado por Libras

consultas de millones de registros en horas? con tablas perfectamente diseñadas y queriess perfectos? C'mon, yo he realizado consultas con calculos acumulativos sobre millones de registros y me devolvian la informacion en 5 minutos, asi que te puedo decir que tus queries no eran perfectos ;)

No he dicho cuantos millones eran amigo..

Estamos hablando de ventas por años, producto por producto, factura por factura, con acumulados y sumas.

Y con tecnologia de hace 10 años...

Saludos

[Libras]

Ahi esta el error producto por producto, factura por factura eso es la muerte pars un rbds, esas operaciones se hacen afectando el mayor numero de registros por operacion(batches)

[ptilotta]

Iniciado por Libras

Ahi esta el error producto por producto, factura por factura eso es la muerte pars un rbds, esas operaciones se hacen afectando el mayor numero de registros por operacion(batches)

Vamos man.. que poca experiencia tienes trabajando con DataWarehouses.

Lo que he narrado es muy habitual y se suele correr en procesos nocturnos.

Dile a las compañias de servicios publicos que un SQL no puede demorar horas.


Saludos

[Libras]

Poca experiencia? Al contrario, he logrado procesos de millones de registros q duraban horas a dejarlos en minutos, porq se de lo q hablo te digo q se pueden mejorar esos procesos de horas, lo q te digo es basado en mi experiencia como dba de sql server, es mas procesos de mantenimiento q duraban horas(index maintenance) los he bajado a unos pocos minutos, a menos q me hables debases de datos de TB(billones de registros) entonces no te acepto una duracion de varias horas, solo por curiosidad, cual es la base mas grande q has manejado?

A y ya le dije a una compañia de sistema de gobierno, y no solo le dije le demostre q se podia disminuir el tiempo

[ptilotta]

El tema amigo,

Es que fue hace unos años atras.-... como te digo, los procesadores y la tecnologia no es la misma ahora.

Generalmente esto se resuelve con tablas resumen, donde se van creando subtotales de lo importante, pero en este caso. tuvimos que llenar cubos.. con mucha info detalle.

No recuerdo cuantos registros eran, pero superaban los 500.000.000 entre 25 tablas.

Saludos

[gnzsoloyo]

Mi estimado: Antes de opinar sobre la validez o no de los JOIN, o incluso hablar de performance, deberías trabajar mucho más en BBDD, en especial en aplicaciones "vivas", es decir aquellas que no consuman recursos de DataWarehouses o DataMarts, y que son en definitiva las que alimentan a esos DW y DM.
Las bases de da,tos operativas n¿NO usan tablas de resumen, porque son tablas calientes, tablas que se están poblando y modificando todo el tiempo, y son los recursos de consolidación de datos los que generan esos resúmenes que tanto adoras.
Pero por detrás, y ANTES de que algo pueda resumirse, hay SQL muy poderoso que usa pura y exclusivamente operaciones de JOIN explicito e implícito, porque si ellos NO ES POSIBLE hacer luego los resúmenes de los DW.
Una base de datos normalizada no sirve si no usas JOINs. Si quieres hablar de otro tipo de BBDD, por ejemplo NoSQL, entonces no estamos hablando del mismo paradigma, por lo que la discusión derivará en la nada.
Ahora bien, para los programadores en general, no existen los JOIN porque simplemente muchos de ellos no los entienden, dado que para comprenderlos y dominarlos se requiere razonar de un modo distinto. tu planteas PROCESOS, y en el SQL no existe SQL basado en procesos, sino procesos que se hacen CON SQL. Un proceso iterativo para construir resúmenes es ineficiente en tablas normalizadas, porque entre otras cosas requiere el consumo de cantidades ingentes de recursos de sistema que son innecesarios, un desperdicio de tiempo de procesos, memoria, cambios de contexto excesivos, y un enorme etcétera. ¿Por qué voy a usar lecturas simples para luego resumir, si puedo resumir al mismo tiempo que hago la consulta... y además de forma más rápida?
¿Por ventura, crees que todos los sistemas bancarios usan SQL con JOIN por capricho? ¿O los sistemas de venta on-line? ¿Crees que no los usan?

Dejando el tema alli, puesto que dudo que lo que pueda decirte para mostrarte otra perspectiva que la que ya tienes instalada en tu sistema lógico haga que reveas tus afirmaciones, volvamos al problema del hilo.

En principio, sin ver la estructura delas tablas, hay cosas que no queda claras en cuanto a donde se originan, pero el punto central es que para hacer optimización hay que al menos reducir la cantidad de registros que lee en la primera tabla. Esa es la que podría ser que tenga baja selectividad y esté devolviendo demasiados registros (más de 150.000). Hay que analizar si es posible agregarle algun valor al WHERE, un índice adicional, o bien cambiar el orden de lectura.
Si el resumen apunta a determinados clientes, hay que basarlo en la tabla relacionada con ellos, que siempre será menor que sus movimientos, por ejemplo. Yo comenzaría por ese lado.
Además hay que verificar que no haya conversiones implícitas (no tratar números como cadenas de texto), y si es posible reemplazar los valores de cadena del WHERE por sus identificadores numéricos (si existen), también ayuda.