Insert

El número de índices sobre una tabla es el factor más predominante para el rendimiento de los insert. Cuantos más índices tiene una tabla, más lenta llegará a ser la ejecución. El comando insert es la única operación que no se puede beneficiar directamente de la indexación porque no tiene filtro where.

Agregar una nueva fila a una tabla supone varias etapas. Para empezar, la base de datos debe encontrar un lugar para almacenar las filas. Para un heap “normal” de una tabla (que no tiene un orden específico de filas), la base de datos puede tomar cualquier bloque de la tabla que tenga suficiente espacio. Es un proceso muy sencillo y rápido, principalmente ejecutado en memoria. Todas las bases de datos tienen que agregar después una nueva entrada haciendo referencia al bloque de datos correspondiente.

Si existen índices sobre una tabla, la base de datos debe asegurarse de que la nueva entrada también pueda encontrarse a través de dichos índices. Por este motivo, se tiene que agregar la nueva entrada a cada uno de los índices de esta tabla. Por lo tanto, el número de índices es un multiplicador del coste del comando insert.

Además, agregar una entrada a un índice es mucho más costoso que insertar uno dentro de la estructura del heap porque la base de datos tiene que conservar el orden del índice y el equilibrio del árbol. Eso significa que la nueva entrada no puede escribirse en cualquier bloque; pertenece a un nodo hoja específico. Aunque la base de datos utiliza el árbol del índice por sí misma para encontrar el nodo hoja correcto, tiene que leer algunos bloques del índice para el recorrido del árbol.

Una vez que el nodo hoja ha sido identificado, la base de datos confirma que existe suficiente espacio libre restante dentro de este nodo. Si no es el caso, la base de datos divide el nodo hoja y distribuye las entradas entre el antiguo y un nuevo nodo. Este proceso afecta también a la referencia dentro del nodo rama correspondiente. Obviamente, el nodo rama puede quedarse sin espacio así que también puede tener que dividirse. En el peor de los casos, la base de datos tiene que dividir todos los nodos hasta el nodo raíz. Este es el único caso en el que el árbol gana un nivel adicional y crecerá en profundidad.

Después de todo, el mantenimiento del índice es la parte más costosa de la operación insert. Está también ilustrado en la Figura 8.1, “Rendimiento del índice en función del número de índices”; el tiempo de ejecución es difícilmente visible si la tabla no tiene ningún índice. Sin embargo, agregar un solo índice es suficiente para incrementar por cien el tiempo de ejecución. Cada índice adicional ralentiza aún más la ejecución.

Para optimizar el rendimiento de insert, es muy importante mantener el número de índices bajo.

Considerando solamente los comandos insert, sería mejor olvidar por completo los índices; es la única manera para obtener los mejores rendimientos para insert. Sin embargo, las tablas sin índices son bastante irreales en el mundo real de las aplicaciones. Generalmente, se quieren volver a recuperar los datos almacenados así que se necesitan índices para mejorar la velocidad de las sentencias. Incluso las tablas tipo bitácora, generalmente en modo sólo escritura, tienen una clave primaria (y su correspondiente índice).

Sin embargo, el rendimiento sin índice es tan bueno que puede tener sentido borrar temporalmente todos los índices mientras se realicen cargas masivas mientras los índices no sean necesarios para ningún otro comando SQL. Eso puede proporcionar una aceleración espectacular que es visible en la gráfica, y de hecho es una práctica muy común en los almacenes de datos (en inglés, data-warehouses).

Si te gusta mi manera de explicar, te encantará mi libro.