También asumo que estás usando Oracle. Y también le recomiendo que consulte la página web del plan de explicación, para empezar. La optimización implica mucho, pero se puede aprender.
A continuación, se incluyen algunos consejos:
En primer lugar, cuando alguien le pide que optimice, casi siempre busca un rendimiento aceptable en lugar del rendimiento máximo. Si puede reducir el tiempo de ejecución de una consulta de 3 minutos a 3 segundos, no se preocupe por reducirlo a 2 segundos, hasta que se le solicite.
En segundo lugar, realice una comprobación rápida para asegurarse de que las consultas que está optimizando sean lógicamente correctas. Suena absurdo, pero no puedo decirte la cantidad de veces que me pidieron consejo sobre una consulta lenta, ¡solo para descubrir que ocasionalmente daba respuestas incorrectas! Y resultó que la depuración de la consulta a menudo resultó también para acelerarla.
En particular, busque la frase "Unión cartesiana" en el plan de explicación. Si lo ve allí, es muy probable que haya encontrado una unión cartesiana no intencional. El patrón habitual para una unión cartesiana no intencional es que la cláusula FROM enumera las tablas separadas por comas y las condiciones de unión están en la cláusula WHERE. Excepto que falta una de las condiciones de unión, por lo que Oracle no tiene más remedio que realizar una unión cartesiana. Con tablas grandes, esto es un desastre de rendimiento.
Es posible ver una unión cartesiana en el plan de explicación donde la consulta es lógicamente correcta, pero asocio esto con versiones anteriores de Oracle.
Busque también el índice compuesto no utilizado. Si la primera columna de un índice compuesto no se utiliza en la consulta, Oracle puede utilizar el índice de forma ineficiente o no utilizarlo en absoluto. Permítanme dar un ejemplo:
La consulta fue:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(El DBMS no era Oracle, por lo que la sintaxis era diferente y olvidé la sintaxis original).
Un vistazo rápido a los índices reveló un índice de Clientes con las columnas (País, Estado, Código postal) en ese orden. Cambié la consulta para leer
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
y ahora se ejecutó en aproximadamente 6 segundos en lugar de aproximadamente 6 minutos, porque el optimizador pudo usar el índice con una buena ventaja. Le pregunté a los programadores de aplicaciones por qué habían omitido el país de los criterios, y esta fue su respuesta:sabían que todas las direcciones tenían un país igual a 'EE. UU.', ¡así que pensaron que podían acelerar la consulta omitiendo ese criterio!
Desafortunadamente, optimizar la recuperación de la base de datos no es realmente lo mismo que eliminar microsegundos del tiempo de cómputo. Implica comprender el diseño de la base de datos, especialmente los índices, y al menos una descripción general de cómo el optimizador hace su trabajo.
Por lo general, obtiene mejores resultados del optimizador cuando aprende a colaborar con él en lugar de tratar de burlarlo.
¡Buena suerte poniéndote al día con la optimización!
