A pesar de la eficiencia del recorrido del árbol, existen casos en los que el índice no trabaja tan rápidamente como sería de esperar. Esta contradicción ha estado alimentada durnate mucho tiempo por el mito del “índice degenerado”. Según este mito, la reconstrucción del índice es la solución milagrosa. Apéndice B, “Myth Directory” está explicado y otros mitos en detalles. Sin embargo, debe asumirse que reconstruir un índice no mejorará el rendimiento a largo plazo. La verdadera razón por la cual una sentencia SQL puede ser lenta, aunque use un índice, puede explicarse con los conceptos vistos anteriormente.
El primer elemento de un índice lento es el encadenamiento de los nodos hojas. Tomando el ejemplo de la búsqueda del valor “57” en la ilustración Figura 1.3, existen dos entradas que cumplen el filtro en la búsqueda. Al menos dos entradas son idénticas, y para ser más preciso, el próximo nodo hoja podría contener nuevas entradas con el valor 57. La base de datos debe leer el próximo nodo hoja para validar si no existen más valores que cumplan los requisitos demandados. Eso significa que la búsqueda por el índice no solo necesita hacer el recorrido, sino que también debe seguir la cadena de los nodos hojas.
La segunda causa de búsquedas lentas aun usando un índice es tener que ir a la tabla. Hasta un nodo hoja simple podría contener varias veces, e incluso centenares, el valor buscado. Los datos correspondientes de la tabla suelen estar diseminados entre varios bloques (ver Figura 1.1, “Nodo hoja del índice y datos de la tabla”). Eso significa que existe un acceso adicional a la tabla por cada valor encontrado dentro del índice.
Una búsqueda por un índice requiere tres etapas: (1) el recorrido del árbol; (2) seguir la cadena de los nodos hojas; (3) devolver los datos de la tabla. El recorrido del árbol es la única etapa que tiene acceso a un número limitado de bloques, corresponde a la profundidad del árbol. Las otras dos etapas deberían tener acceso a muchos bloques que pueden ser la causa de la lentitud durante una búsqueda a través de un índice.
El origen del mito de los índices lentos es debido a la falsa creencia de que la búsqueda sólo recorre el índice, así que genera la idea de que el índice lento puede estar causado por un árbol “roto” o “desequilibrado”. Lo cierto es que se puede analizar de qué manera usa la base de datos sus índices. De hecho, la base de datos Oracle es bastante locuaz al respecto y tiene tres operaciones diferentes que describen perfectamente la búsqueda por el índice:
- INDEX UNIQUE SCAN
El
INDEX UNIQUE SCANrealiza solamente el recorrido del árbol. La base de datos Oracle utiliza esta operación si una restricción única (constraint) asegura que el filtro de la búsqueda se encuentra una única vez.- INDEX RANGE SCAN
El
INDEX RANGE SCANrealiza el recorrido del árbol y sigue la cadena de los nodos hojas para encontrar todas las entradas correspondientes al filtro. Es la operación más segura en caso de encontrar varias entradas que se corresponden con el filtro.- TABLE ACCESS BY INDEX ROWID
Una operación
TABLE ACCESS BY INDEX ROWIDtrae el registro desde la tabla. Esta operación se realiza (frecuentemente) por cada registro traído desde un recorrido de índice hecho previamente.
El punto más importante es que un INDEX
RANGE SCAN potencialmente puede leer una parte amplia desde el
índice. Si existe más de un acceso por cada registro, la sentencia SQL
puede empezar a ser lenta aun usando un índice.
Si te gusta mi manera de explicar, te encantará mi libro.
