FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Optimización de consulta
Buenas noches:
El motivo de mi hilo es para solicitar de su apoyo en la optimización de esta consulta que
Ya que actualmente me tarda en mostrar los registros en un tiempo de 1 minuto 30 segundos estamos hablando de 4 millones 162 mil registros, el servidor es un IBM de 8 GB con procesador Intel Xeon E3 1220 v3 a 3.10 GHZ el firebird es Firebird-2.5.4.26856_0_x64 modo classic ya intente configurando el firebird.conf pero ya me duele la cabeza llevo todo el día pegado a la PC, espero ustedes tengan algún comentario Gracias!! |
#2
|
||||
|
||||
El firebird.conf no necesitas modificarlo para nada.
Lo que necesitas es que los campos implicados en consulta (where, and, or, etc.) tengan su índice o sean claves. Mira el plan usado y optimiza la consulta según lo que indique. Para ayudarte necesitamos la estructura de la base de datos, cosa que no has dicho. |
#3
|
|||
|
|||
Hola,
Aunque el volumen de datos es importante la consulta es bastante sencilla por lo que haciendo lo que te indica Casimiro tiene mejorar muchisimo. Empieza por ahi.
__________________
Saludos, Bitman |
#4
|
||||
|
||||
Yo creo que tenes un problema "grave" aca
Pensando desde Delphi, porque tendrias un caracter (o string, peor aun) para diferenciar entre un "tipo de algo" Lo mas natural seria usar un enumerativo. Y los enumerativos son tipos de datos numericos (byte, word, integer, etc). Y las operaciones con tipos de datos numericos son mucho mas rapidas que con strings o carácteres |
#5
|
||||
|
||||
Si no sabes interpretar el plan, como yo digo siempore, divide y vencerás.
Así sabrás dónde se va el tiempo. 1.- quita todas las condiciones del where y mide el tiempo. 2.- Si ha mejorado, incluye una condición, y vuelve a medir. 3.- Así hasta que veas dónde está el cuello de botella y al menos sepas dónde mirar. Ese left join no me gusta nada.... Necesitas los 4 M de registros? Puedes poner otra condición que limite los registros involucrados como una fecha por ejemplo ? Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#6
|
|||
|
|||
Gracias por su respuestas, como lo indicaron fui dividiendo la consulta hasta que me percate que tarda al ordenar (ORDER BY A.FOLIO) dicho campo es un char (Ejem. 'B000000010, B000000011..... n) lastimosamente esta consulta viene dentro un sistema llamado Microsip y por ende no puedo modificarlo, pero si puedo mandar un reporte ya que esta afectando la operación de la empresa donde laboro (Tiendas de abarrotes tipo Chedrahui, Soriana), si existe forma de optimizar el order by para darle un poco de agilidad me gustaría me comentaran, otra de las cosas que se me ocurrió en base a sus comentarios es sugerir la separación del campo Folio 'B000000010' serie char B integer 10 ya que como estamos hablando de ventas de mostrador pueden tener diferente serie pero el entero se puede repetir ejemplo A1, B1, C1
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Optimización consulta SQL con EXISTS en Firebird 2.5 | briast | SQL | 0 | 05-11-2013 11:57:20 |
Optimización! Optimización! | PiornoCKA&G | Varios | 1 | 31-12-2006 20:45:30 |
Optimización de los índices | AMINOA2R | Firebird e Interbase | 13 | 04-08-2005 17:18:50 |
optimizacion del SQL | seb@ | SQL | 1 | 22-09-2004 19:55:24 |
Optimizacion | manuelpr | Conexión con bases de datos | 3 | 30-07-2004 17:26:24 |
|