Otra consulta más con un número de bloques leídos muy alto, pero además a esta consulta no la acompaña el tiempo de respuesta, tarda 3’’ en devolver 0 filas.
Lo primero que vamos a hacer es generar el tkprof. Con esto vamos a poder determinar qué está sucediendo internamente en el tiempo de ejecución, para que 0 filas devueltas lean más de 750.000 bloques con un tiempo de 3’’
Analizando en detalle el tkproff vemos una operación nested loops con unos índices altos
Esta operación del row source, es la que más consume, con más de 700.000 bloques leídos en memoria. Otro punto más que nos llama la atención de este cruce es el tiempo.
Si miramos el árbol de ejecución, vemos que ese salto tanto en bloques leídos como en tiempo de ejecución se produce al acceder a la tabla particionada
En este punto, es donde deberíamos atacar para optimizar la consulta.
Reajustados la SQL y contrastamos los tkproff
Y ahora la consulta vuela, hemos reducido el número de bloques, pasando a leer ahora 686 cuando la cifra original era más de 750.000. Con esta optimización el tiempo de CPU también ha bajado, de ejecutarse unos 3’’ a ejecutarse 0,004’’.