Noté que muy pocas personas entienden cómo funcionan los índices en SQL Server, especialmente las columnas incluidas. Sin embargo, los índices son la mejor manera de optimizar las consultas. Al principio, tampoco entendí la idea de las columnas incluidas, pero mis experimentos demostraron que son muy útiles.
Supongamos que tenemos la siguiente tabla y consulta:
CREATE TABLE Person ( PersonID int, FirstName varchar(100), LastName varchar(100), Age int, … … ) SELECT FirstName, LastName, Age FROM Person WHERE FirstName = 'John' and LastName = 'Smith'
Está claro que PersonID es una clave principal. Supongamos que tenemos un índice por nombre y apellido, llamémoslo IX_Person_FirstNameLastName. El plan de ejecución para dicha consulta será el siguiente:
- Ubicar todas las líneas con el nombre y apellido especificados con la ayuda del árbol de índice IX_Person_FirstNameLastName
- Detectar la ubicación real de la línea en el disco en las hojas de índice, ir a la ubicación real y leer la edad.
Ahora, consideremos que esta consulta se ejecuta con bastante frecuencia. Tenemos que ejecutar 2 pasos cada vez. ¿Se puede optimizar? En el caso de MS SQL Server, no hay problema:puede incluir valores directamente en el índice con la ayuda de la opción INCLUDE.
CREATE INDEX IX_PERSON ON Person ( FirstName, LastName ) INCLUDE(Age)
Ahora, este campo no se usa durante la indexación, pero se incluye en el índice. ¿Qué problemas podemos enfrentar en este sentido? Cuando indexamos una tabla por un campo determinado, el servidor de la base de datos debe construir un árbol de índice por este campo. Esto significa que necesitamos cambiar el árbol de índices al cambiar el valor. Cuando los valores se modifican intensamente, se convierte en una tarea difícil y problemática para el servidor. Cuando la actualización se vuelve demasiado masiva, a veces es más fácil eliminar el índice. Index optimiza en gran medida la búsqueda pero afecta negativamente las operaciones de inserción, eliminación y actualización.
Si un campo simplemente se incluye en un índice, no se usa durante la construcción de un árbol de índice y no lo afecta, pero el El valor se puede encontrar fácilmente en la hoja de este árbol. Cuando se realiza una búsqueda por apellido y nombre, el servidor busca todos los nombres y apellidos del árbol, y cuando llega a la hoja (encuentra el valor de índice requerido), además del puntero a la ubicación física de los valores de línea, también contiene valores de campo incluidos en el índice. Significa que no hay necesidad de dar el segundo paso para cambiar a la ubicación física de la línea y leerla desde allí.
Dado que no necesita cambiar el árbol al modificar los datos de edad, todo esto no afecta mucho las operaciones de modificación de datos. No necesitamos cambiar el índice, solo necesitamos cambiar los valores en la hoja del árbol. Es por eso que incluso un cambio masivo del campo Edad no tendrá un gran impacto en el rendimiento. Sin duda afectará, pero no tanto.
Hasta donde yo sé, los valores del índice agrupado se incluyen automáticamente en el nivel hoja, pero esto debe verificarse con la especificación.
Entonces, ¿cuándo es beneficioso el uso de los campos incluidos? Cuando se usan con frecuencia en los resultados de las consultas, pero se cambian de vez en cuando. Un ejemplo es una tabla de transacciones bancarias. Dicha tabla puede constar de los siguientes campos:número de cuenta, tipo de transacción, fecha, suma. No tiene sentido indexar por la suma, pero podemos incluirlo en el índice y acelerará significativamente la consulta.
Para recuperar el efecto real de la indexación, las consultas no deben seleccionar todos los campos, es decir, debemos olvidarnos de la tabla SELECT * FROM. Siempre vuelva a calcular solo los campos que realmente necesita. Y si sus valores llegan a estar en el índice, la velocidad de ejecución puede ser bastante alta.
Herramienta útil:
dbForge Index Manager:práctico complemento de SSMS para analizar el estado de los índices SQL y solucionar problemas con la fragmentación de índices.
