Índices para mejorar el rendimiento, ¿buenos o malos?

“Los índices son buenos para el rendimiento”

En términos generales, los DBA y los desarrolladores pasan una buena cantidad de su tiempo de rendimiento tratando de encontrar qué índices agregar a una base de datos para mejorar el rendimiento. Si una consulta específica tiene problemas de rendimiento, una de las herramientas más sólidas para solucionar el problema es la indexación. Esta es una verdad indiscutible, casi dogmática. Universalmente conocida, como el hundimiento de la Armada Invencible.

“Los índices son malos para el rendimiento”

Sin embargo, ¡Sorpresa!  los índices no son del todo buenos. Dejando a un lado el hecho de que algunos índices, particularmente los índices con baja cardinalidad pueden dañar el rendimiento, los índices se almacenan físicamente en el disco. Esto significa que no sólo ocupan espacio en el disco, sino que también perjudican el rendimiento de las operaciones que insertan, actualizan o eliminan datos. Cada índice adicional representa un lugar más en el disco y Db2 tiene que insertar, actualizar o eliminar los mismos datos que están almacenados en la tabla. Los índices también deben mantenerse a través de reorganizaciones y estadísticas de ejecución y deben respaldarse con el resto de la base de datos. Esta parte ya no es tan universalmente conocida, como la derrota de la contraarmada inglesa primero en La Coruña y luego en Lisboa y Azores.

Teniendo esto en cuenta, hay que establecer nuestras prioridades de rendimiento a la hora de calcular cuántos índices hay que agregar. Estas prioridades pueden ser diferentes de una tabla a otra dentro de la misma base de datos.

Muchos consultores de Db2 cuentan historias de terror como entrar en un cliente y encontrar 30 o más índices en una tabla que es fundamental para el rendimiento de OLTP. Al menos un consultor que conozco afirma haber costeado la universidad de sus hijas y sus respectivas bodas eliminando índices.

¿Cuántos índices hay que crear, entonces? No hay un número mágico para el número correcto de índices en una tabla. Para Db2, a menudo un buen índice que ayuda a múltiples consultas es mejor que un índice perfecto para cada consulta.

A menudo, es probable que las bases de datos en el extremo del espectro de análisis / BI / Data Warehouse tengan más índices que los del extremo del espectro OLTP / procesamiento de transacciones / comercio electrónico. Esto se debe a que la prioridad en las bases de datos analíticos son las consultas, mientras que la prioridad en las bases de datos de procesamiento de transacciones a menudo son las pequeñas actualizaciones, inserciones y eliminaciones de una sola fila que los índices adicionales pueden ralentizar.

Identificación de índices no utilizados

Con Db2 9.7, IBM introdujo una columna en varias vistas del sistema, incluido SYSCAT.INDEXES, que registra la última vez que se utilizó un objeto. Esta columna, llamada LASTUSED, no se actualiza inmediatamente después del uso de un objeto para evitar el impacto en el rendimiento, pero generalmente es precisa. Hubo algunos problemas con los primeros fixpacks de 9.7 (allá por 2010), por lo que los números realmente no deberían considerarse exactos en estas versiones antiguas. Sin embargo, en los fixpacks posteriores de 9.7 y las versiones posteriores, esta información es una herramienta muy valiosa.

Hay que tener en cuenta si existen otros requisitos tales como que algunos índices solo se puedan usar a fin de mes, trimestre, fin de año o durante algún período anual especial como el Black Friday.

Planificación de marcha atrás

Todo lo que hagamos en un entorno Db2 debe tener un plan de marcha atrás. Antes de borrar un índice, hay que asegurarse de tener la sintaxis para recrearlo (y mantenerlo durante al menos unos meses por si fuera necesario dentro de varios meses), para lo cual db2look es una gran herramienta. Volver a crear un índice si se encuentran problemas de rendimiento es casi siempre rápido y fácil.

Verificación del impacto

Para comprender el impacto de un índice descartado, es mejor obtener una línea de base en un entorno de prueba de carga, luego descartar el índice y repetir la prueba de carga para ver qué diferencia hay, si es que hay alguna. El criterio para el éxito es la falta de degradación. Es posible que no veamos mejoras para cada índice, pero aún estamos ahorrando espacio en disco y otros recursos.

Primero habría que hacer los borrados en un entorno no productivo, preferiblemente tomando mediciones antes y después del borrado efectuado para ver si hay diferencias significativas.

Para un índice realmente no utilizado, es posible que no veamos un impacto positivo, pero aun así es beneficioso eliminarlo.

Resumen

Eliminar los índices puede ayudar al rendimiento o a prevenir la degradación del rendimiento, particularmente para entornos OLTP. Puede liberar espacio en disco tanto para la base de datos como para las copias de seguridad y hacer que las copias de seguridad y el mantenimiento de la tabla (Reorganizaciones y estadísticas) se ejecuten más rápido.

Fuente:  https://www.virtual-dba.com/dropping-indexes-improve-db2-performance/