![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Así, sólo con la SQL es bastante difícil saber dónde puede estar el problema.
Lo primero sería que comentaras con qué motor trabajas (esto por situarnos), luego lo suyo sería que intentarás acceder al PLAN DE EJECUCIÓN de la consulta. Si supueramos el gestor y kla herramientas que estás utilizando podríamos decirte cómo obtenerlo. Una vez visto el plan, deberías poder saber qué parte de la consulta está tardando más de la cuenta. El SELECT, la INSERCIÓN (triggers), las ORDENACIONES, el GROUP BY, la SUBSELECT,... Y una vez que sepas la parte que está tardando podrás intuir qué es lo que hay que optimizar. Imagino que tienes definidas PK's, índices,...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi ![]() P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
|
#2
|
||||
|
||||
|
Cita:
Hay maneras mucho mas faciles de solventar tu problema: - Podrias definir claves primarias compuestas - O podrias usar un trigger para validar la insercion Por otra parte, una consulta SQL de ese tamaño a mi me resulta alarmante Otros problemas que hacen que sea lenta es que usas mucho strings, convertis entre varios tipos de datos, y no es una subconsulta, son tres |
|
#3
|
||||
|
||||
|
Es que eso no es un "insert", eso es un insert con un select anidado...
y un count distinct y un sum, y otro sum, y un count(*) !!! y otro exists con otro select anidado, y un not exists con otro select anidado... y un group by y todo aderezado de montones de campos de texto, concatenaciones de campos, ... No es un insert, es un desastre ![]() Me temo que tendrás que ir poco a poco, probando cada parte del código para ir mejorándolo y afinándolo.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal Última edición por Casimiro Noteví fecha: 12-05-2016 a las 02:50:14. |
|
#4
|
||||
|
||||
|
Ahi lo que veo mas problematico son los EXIST y mas que todo el NOT EXIST. Normalmente eso no es muy eficiente de hacer.
Que el SELECT de insercion sea "grande" no es en si el problema (es posible hacer inserciones de 1-4GB -dependiendo de motor y parametros- en unos <200 segundos en hardware medio medio, siempre y cuando todo este alineado ). Asi que pon atencion a lo que te estan diciendo que eso se puede mejorar bastante...
__________________
El malabarista. |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Consulta lenta | DamianG | Firebird e Interbase | 6 | 20-11-2012 15:06:16 |
| Consulta sql lenta la primera vez | lledesma | Conexión con bases de datos | 2 | 07-07-2008 12:58:36 |
| Ayuda con consulta lenta, lenta, lenta | Gregory Mazon | Firebird e Interbase | 22 | 27-06-2007 10:56:38 |
| Consulta muy lenta | Walterdf | Conexión con bases de datos | 2 | 25-08-2004 19:37:57 |
| lenta la consulta. | digital | Conexión con bases de datos | 2 | 10-09-2003 16:38:13 |
|