¿Cuándo podemos decir que una consulta es lenta?

Cuando tarda más de 15 segundos en mostrar sus resultados. En épocas anteriores era admisible que para obtener un informe se tuviera que esperar media hora o inclusive más pero ahora si tarda más de 15 segundos los usuarios ya empiezan a desesperarse.

Entonces, veamos los motivos que pueden hacer lenta una consulta y como mejorar los tiempos:

1. No se está usando un índice. En las tablas pequeñas usar un índice o no es casi lo mismo pero en tablas que tienen miles o millones de filas la ganancia en velocidad es impresionante cuando se usa un índice.

2. Transacciones mal gestionadas. En general deberías usar SNAPSHOT y que la transacción sea READ-ONLY

3. Muchas filas modificadas o borradas. Si el informe necesita obtener los datos de filas que han sufrido muchas actualizaciones y aún no se recolectó la basura de esas actualizaciones la obtención de los datos será más lenta.

4. Empezó la recolección de basura en un mal momento. La recolección de basura hará que todas las operaciones en la Base de Datos sean más lentas que lo habitual. Para solucionarlo puedes revisar frecuentemente si la diferencia entre la transacción más antigua y la transacción activa se acerca al intervalo de recolección. Si lo hace entonces tienes dos soluciones: aumentas el intervalo por ejemplo a 30.000 ó lo dejas en 0 y luego te encargas de ejecutar la recolección de basura manualmente (pero no te olvides de hacerlo).

5. Estás usando una UDF que devuelve caracteres. Muchas UDFs devuelven una cantidad fija de caracteres (por ejemplo: 32.000). Eso implica que si por ejemplo las filas a mostrar son 10.000 el Firebird deberá ordenar 300 Mb de datos, lo cual es exageradamente mucho. Aquí la solución es usar CAST para reducir la cantidad de caracteres que devuelve la UDF.

6. Estás usando la claúsula ORDER BY en un stored procedure seleccionable. Esto ocurrirá aunque la columna usada en el ORDER BY tenga un índice en la tabla original. ¿Por qué? porque los stored procedures son código precompilado y por lo tanto no cambiarán cuando sean ejecutados. Eso implica que escribir:


SELECT
   *
FROM
   MiStoredProcedureSeleccionable
ORDER BY
   MiColumna

es un error.

Si necesitas mostrar los datos ordenados lo correcto es que la cláusula ORDER BY se encuentre adentro del stored procedure, no afuera de él.

7. Estás usando un disco lento. Los discos duros tienen distintas velocidades de acuerdo a su capacidad y a su tecnología. SCSI es mejor que SATA y ésta es mejor que PATA.

8. Tienes el Sistema Operativo y la Base de Datos en el mismo disco duro. Tener la Base de Datos en su propio disco, donde solamente se encuentre ella y nada más, mejora en mucho la velocidad.

9. Tienes poca memoria RAM. En este caso obligarás al Sistema Operativo a realizar frecuentes intercambios entre memoria y disco (a eso se le conoce como swap y es un proceso muy lento). Para aumentar la cantidad de memoria que el Firebird usa puedes modificar el archivo FIREBIRD.CONF

10. Estás usando SuperServer en una computadora multi-core y no pusiste el valor de CPU Affinity en el archivo FIREBIRD.CONF. Por defecto SuperServer solamente utiliza el primer procesador aunque la computadora tenga varios, pero cambiando el valor de CPU Affinity se le puede decir cuales procesadores usar.