Muy lento Sql
 

Hola a todos


Tengo una tabla que tiene 205793 registros
Otra que tiene 227
Otra que tiene 41756

Bien creo indices y aun sigue lento si utilizo un left join me da un error de espacio (Se queda sin espacio los archivos temporales TMP)

La consulta es muy simple es asi

select a.key_plan_ctas,sum(debe) debe,sum(haber) haber
from cab_fac c,aux_diario a
Where c.key_cab_fac=a.key_viene
and c.estado_fac='T'
and a.tipo='I'
group by a.key_plan_ctas


Esta instruccion se ejecuta lenta (Hay indices creados para key_viene y key_cab_fac )

Esta cuelga el aplicativo

select a.key_plan_ctas,sum(debe) debe,sum(haber) haber
from cab_fac c,aux_diario a
LEFT JOIN plan_ctas P on a.key_plan_ctas=p.key_plan_ctas
Where c.key_cab_fac=a.key_viene
and c.estado_fac='T'
and a.tipo='I'
group by a.key_plan_ctas

Que puedo estar haciendo mal, por sus comentarios muy agradecido

Consulta de SQL
 

select a.key_plan_ctas, sum(debe) debe, sum(haber) haber
from cab_fac c,aux_diario a
LEFT JOIN plan_ctas P on a.key_plan_ctas=p.key_plan_ctas
Where c.key_cab_fac=a.key_viene
and c.estado_fac='T'
and a.tipo='I'
group by a.key_plan_ctas

debe de que tabka es??? de cab_fac o Aux_diario debes agregar el alias
donde es sum(debe) as debe
no debes poner la segunda tabla despues del from solo la tabla principal
me podes decir que es lo que queres listar? no entiendo la consulta, vos queres listar del plan de cuentas los totales del debe y haber (mayorizar) pero para que queres los encabezados de factura???:confused: y para que traes el join ???:(

para mi seria asi:
siendo aux_diario mi tabla principal

select a.key_plan_ctas, sum(a.debe) as debe, sum(a.haber) as haber
from aux_diario a
Where a.tipo='I'
group by a.key_plan_ctas
si podes mandame las estructuras y lo que queres listar....

Luis Roldan
laromdp@infovia.com.ar

Hola IvanD.

Muchas veces no basta con que hayan indices creados. Cada motor elabora un Plan de ejecución para tu consulta. Algunos optimizan basados en una serie de reglas predefinidas, otros en base a complicados cálculos de costes... en fin.

Lo recomendable no es solo crear los indices, sino conocer tu motor lo suficiente como para saber las reglas del juego, e inquirirle sobre el plan de ejecución que está tomando, que regularmente es posible, pero que varía la forma de hacerlo entre motores.

Por último, si por algúna razón el motor decide no usar indices... regularmente hay forma de forzarle (al menos en interbase/firebird y en oracle) mediante hints a seguir el plan que vos consideres que es mas óptimo.

Hasta luego.

;)

Hola Luis

Gracias x tu interes

Te comento, tengo un sistema integrado de facturacion y contabilidad, en una tabla grabo todos los datos de una factura (ventas,iva,descuentos,recargos etc) los cuales tambien grabo su key_plan_ctas (En la tabla plan_cuentas esta tambien key_plan_ctas (es un integer))

Pues bien como te das cuenta lo uno con cab_fac porque ahi tengo la cabeza (Fechas, estado etc) y con plan cuentas para que me saque el codigo contable para generar un asiento contable, el join lo utilizo porque puede ser que no me hayan configurado una cuenta contable (parametro en ventas ), es decir que el campo aux_diario (a.key_plan_ctas) puede o no tener valor

Mi preocupacion general es aque el query es super lento y ademas en ocasiones se muere el aplicativo por el error antes indicado

De antemano Gracias

Hola Juan,
Efectivamente utilizo firebird 1.0 y Ibexpert (Cuando ejecuto la consulta me muestra que utilizo un plan (Donde utiliza el indice key_viene), me podrias indicar donde puedo buscar ayuda sobre los Hinst, Gracias,

Pienso que tal cantidad de registro no es para que la base de datos se ponga tan pesada


Gracias

Sobre los hints encontrarás información en la documentación de Interbase 6, aunque ahora no la tengo a mano y no puedo direccionarte directamente al libro correcto, aunque me suena el SQL Reference

Siempre que el optimizador no decida hacer un producto cartesiano completo.. que sería de 1,950,631,999,316 registros.. :D :D

Seguramente no está haciendo el producto cartesiano, pero igualmente puede estar tomando una decisión equivocada.

Hasta luego.

;)

Nuevamente Gracias

Pero me podrian ayudar orientandome, donde poder ubicar alguna idea de porque ocurre esto, imagino que ustedes tienen tablas mas grandes y no tienen estos problemas , (El problemas es cuando ocurre un sum)


El cliente me esta volviendo loco y mi cabeza a punto de explotar :(

Gracias

read uncommited
 

Trata poner esta instruccion en tu query, asi no bloquearas las tablas.
Set transaction isolation level read uncommited
select ...

Buenas @makina!

Quisiera comentar que el tema tiene mas de 5 años de antiguedad, además de que en tu respuesta veo algunos inconvenientes:

• Hasta ahora, no se mencionó que hubiera problema con el bloqueo de tablas, hasta en tu mensaje
• Establecer el nivel de aislamiento de esa manera podría ocasionar otros problemas... sobre todo con la arquitectura de Interbase
• Puede ser que IVAND o cualquier otro que leyera este post no se diera cuenta que, si esta instrucción tuviera éxito, leería datos de transacciones que incluso no han sido confirmadas (commit), y quizas necesite un mayor nivel de aislamiento, por ejemplo, para que el resultado sea consistente
• No recuerdo ya claramente si Interbase 6 soporta ese nivel de aislamiento, pero creo que el mas bajo que soportaba era READ COMMITTED
• La forma de cambiar el nível de aislamiento de la transacción varía de capa de conexión a capa de conexión: no es igual en BDE que en IBX que en DBX

Un saludo.