Optimización de consulta

[nuxbaster]

Buenas noches:
El motivo de mi hilo es para solicitar de su apoyo en la optimización de esta consulta que

Código SQL [-]
SELECT
A.*, A.IMPORTE_NETO+A.IMPORTE_DONATIVO+A.TOTAL_IMPUESTOS AS IMPORTE_TOTAL
,
B.NOMBRE AS CAJA
FROM
DOCTOS_PV A
LEFT JOIN CAJAS B
ON A.CAJA_ID = B.CAJA_ID
WHERE ((A.TIPO_DOCTO='V'))
ORDER BY A.FOLIO

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!!

[Casimiro Notevi]

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.

[Toni]

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.

[[AgustinOrtu]]

Yo creo que tenes un problema "grave" aca

Código Delphi [-]
WHERE ((A.TIPO_DOCTO='V'))

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

[[fjcg02]]

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

[nuxbaster]

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

[Casimiro Notevi]

Crea un índice para ese campo.

[[fjcg02]]

Empezado por Casimiro Notevi

Crea un índice para ese campo.

Sería la solución.

Saludos

[nuxbaster]

Estimados compañeros:

Quiero agradecer su apoyo a mi consulta, este escrito es para informarles acerca de la solución (de lentitud) durante mi investigación y con la infinita ayuda de cada uno de ustedes he logrado entender cosas que antes no y es por eso que si algún día andan en México les tendré un six y un rico consome de barbacoa ....

Gracias a todos los que se tomaron un poco de su valioso tiempo, mi consulta inicialmente tardaba 1 minuto 15 segundos (4 millones 162 mil registros) y con las correcciones sugeridas (Gracias Casimiro: Crear un indice en el campo utilizado por order by). La consulta da esa sensación de rapidez tardando únicamente de 4 a 6 Segundos.

No me queda más que dar por cerrado este tema.

PD. Saber que ustedes lo hacen posible es lo mejor (Los de soporte del sistema su solución fue haga su respaldo y empieza con una base de datos en blanco)

Gracias,

[Casimiro Notevi]

Por aquí estaremos cuando te haga falta

[[fjcg02]]

Ahora ten cuidado...

has puesto el listón muy alto ( de 1' 45s a 4 s ) y tus jefes esperarán ese rendimento en todo lo que hagas, jejeje

Un saludo