Las cinco consideraciones principales para el diseño de índices de bases de datos en SQL Server

Los índices de la base de datos se utilizan para acelerar las diferentes operaciones de la tabla. Sin embargo, antes de crear un índice, es importante saber si realmente necesita un índice. Y si necesita crear un índice, ¿cuáles son los puntos importantes que debe tener en cuenta? Aquí es donde entra en juego el diseño del índice de la base de datos.

Este artículo tiene como objetivo responder a estas preguntas sobre el diseño de índices de bases de datos y arrojar algo de luz sobre algunas de las principales consideraciones que un desarrollador de bases de datos debe tener en cuenta al diseñar un índice.

1. Tamaño de la mesa

La primera pregunta que debe hacerse un desarrollador de base de datos antes de crear un índice es si la tabla es lo suficientemente grande como para usar índices de manera eficiente. Si el tamaño de la tabla es pequeño, el motor de SQL Server puede escanear la tabla completa más rápidamente que buscar la tabla a través de un índice. Los índices en tal caso no tienen ningún uso y crean una sobrecarga al realizar operaciones de base de datos.

2. Tipos de columna

Los índices deben crearse en una columna de clave principal o en cualquier columna que contenga valores únicos y que tenga una restricción NOT NULL. Además, es recomendable crear índices en columnas numéricas, ya que las columnas numéricas tienden a tener más valores únicos en comparación con las columnas no numéricas. El diseño deficiente del índice de la base de datos usa índices en columnas que tienen muy pocas entradas únicas y pueden generar consultas que consumen mucho tiempo.

Considere una tabla llamada Pacientes que contiene cientos de miles de registros. La tabla Pacientes contendría una columna llamada "Género" que solo puede tener dos valores únicos "Hombre" y "Mujer". Si crea un índice en la "Columna de género", los registros se ordenarán en orden alfabético ascendente o descendente.

Entonces, si tiene un millón de registros en la tabla Pacientes y el número de pacientes masculinos y femeninos es igual, en el índice, el primer medio millón de registros tendrá el género "Femenino" y el segundo medio millón tendrá el género "Masculino". Ahora, si desea buscar una mujer que exista en la fila 490 000 de los registros femeninos, el motor de SQL Server tendrá que escanear 490 000 registros. Por otro lado, con valores numéricos únicos, la búsqueda puede ser extremadamente rápida ya que los índices de SQL Server se almacenan en forma de árboles B +, por lo que los valores numéricos en los nodos del árbol pueden acelerar las operaciones de la base de datos.

3. Número de índices

Oficialmente, puede crear un índice agrupado y tantos índices no agrupados como desee para cada tabla de base de datos. Sin embargo, es un buen diseño de índice de base de datos crear un índice agrupado y solo un número limitado de índices no agrupados absolutamente necesarios. La creación de demasiados índices no agrupados puede ralentizar las operaciones de actualización e inserción porque cuando se actualiza o inserta un registro y se cambia el valor de una columna, todos los índices asociados deben actualizarse.

Considere un escenario donde tenemos dos índices no agrupados, el primer índice ordena los registros por edad y el segundo índice ordena los registros por género y edad.

Aquí está el primer índice:

Y aquí está el segundo:

Ahora, si un registro con 40 años de edad debe actualizarse a 15 años por algún motivo, entonces el primer índice deberá actualizarse para mover el registro de la séptima posición (40) a la segunda posición para mantener el índice ordenado. De manera similar, en el segundo índice, el registro en el cuarto índice se moverá al segundo índice. Hay que hacer muchas reorganizaciones. Por lo tanto, es aconsejable mantener el número de índices al mínimo para las columnas que se actualizan regularmente cuando se piensa en el diseño de índices de bases de datos. Además, una columna no debe usarse en múltiples índices no agrupados.

4. Ubicación de almacenamiento de índices

La ubicación de almacenamiento de un índice puede afectar el rendimiento de las consultas que utilizan el índice y, por lo tanto, también forma parte de un buen diseño de índice de base de datos. De forma predeterminada, un índice agrupado se almacena en el mismo grupo de archivos que la tabla en la que se crea el índice. Para índices no agrupados, el índice se puede almacenar en el mismo grupo de archivos o en diferentes grupos de archivos que abarcan varias unidades de disco. El rendimiento de las consultas de los índices no agrupados se puede mejorar significativamente almacenando los índices no agrupados en varias unidades de disco. Esto se debe a que el rendimiento de entrada/salida de la consulta mejorará como resultado de la distribución de los datos en diferentes áreas de la unidad.

La ubicación de almacenamiento predeterminada de los índices también se puede cambiar especificando un valor para la opción FILLFACTOR. Dado que los índices se almacenan físicamente en forma de árboles B+, los datos del índice se almacenan en páginas hoja. Con la opción FACTOR DE RELLENO, puede establecer el porcentaje de las páginas de nivel de hoja que se llenarán. Por ejemplo, si establece el valor de FILLFACTOR en 70%, solo el 70% del espacio total de la página de nivel de hoja se llenará con datos de índice. El 30 % restante se dejará para el crecimiento automático de los datos del índice en el futuro.

5. Tipos de índice

Otra consideración extremadamente importante en el diseño de índices de bases de datos es el tipo de índice a utilizar. En un artículo anterior (agregue un enlace al artículo "Cuándo usar un índice agrupado o no agrupado") expliqué la diferencia entre índices agrupados y no agrupados. También expliqué qué son y cómo se pueden usar. La decisión de elegir un índice agrupado o no agrupado es crucial y debe analizarse detenidamente.

Los siguientes puntos deben tenerse en cuenta al decidir qué tipo de índice elegir.

1. Para las columnas que se utilizan en consultas SELECT/JOIN/GROUP BY/BETWEEN, utilice índices agrupados.
2. Utilice índices no agrupados para columnas en las que solo desee recuperar valores de esa columna específica y no de las otras columnas de la misma fila. Las consultas SELECT que recuperan varios registros usando un índice no agrupado pueden ser lentas porque el motor de SQL Server primero busca los valores de columna en los que se crea el índice y luego, usando la referencia de fila para el valor de columna, se recuperan los registros de las tablas de base de datos reales. .
3. Para las columnas que a menudo se someten a operaciones INSERTAR y ACTUALIZAR, utilice un índice no agrupado. Asegúrese de no usar una columna en varios índices no agrupados, ya que eso puede ralentizar las consultas de actualización. Los índices agrupados pueden ser lentos para las operaciones INSERT/UPDATE porque se debe actualizar la fila completa en lugar de solo un valor de columna, como es el caso de los índices no agrupados.
4. Dado que solo puede crear un índice agrupado, en el caso de que necesite varios índices, use índices no agrupados. Sin embargo, si el espacio en disco es una preocupación importante, mantenga la cantidad de índices no agrupados al mínimo.

Otras consideraciones

Aunque estas son las cinco partes más importantes del diseño de índices de bases de datos, no lo son todo. Es importante especificar el orden correcto de las columnas en los índices. Como regla general, las columnas que se utilizan para la toma de decisiones en las cláusulas WHERE y las condiciones como mayor que (>), menor que (<), etc., deben colocarse antes de las columnas que no están involucradas en estas cláusulas. En el caso de varias columnas en la cláusula WHERE, los nombres de columna más distintivos deben mencionarse al principio de la definición del índice.

Además del diseño del índice de la base de datos, el diseño de consultas también juega un papel importante en el uso eficiente del diseño del índice. Para optimizar el mantenimiento del índice, en lugar de escribir varias consultas que operan en una pequeña cantidad de filas, intente escribir menos consultas que afecten a una mayor cantidad de filas de la tabla.

Conclusión

Este artículo explica algunas de las principales consideraciones que un desarrollador de base de datos debe tener en cuenta al analizar el diseño del índice de la base de datos. El artículo también explica la lógica detrás de estas consideraciones y contiene más sugerencias para asegurarse de que el diseño del índice de su base de datos sea eficiente.