Función de los índices en bases de datos SQL

Curso de Optimización de Bases de Datos en SQL Server

Contenido del curso

Introducción al curso

Conociendo los índices

Optimización de consultas

Queries más inteligentes

Optimización de base de datos

Monitoreo

Conclusión

31
Optimización de Consultas y Rendimiento de Bases de Datos
00:48 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:02

Función de los índices en bases de datos SQL

Curso de Optimización de Bases de Datos en SQL Server

Clase 7 de 31

Clase 7 / 31

Recursos

Cuando una consulta tarda demasiado o consume recursos excesivos en el servidor, es probable que haga falta una pieza fundamental en la base de datos: un índice bien configurado. Comprender cómo funcionan los índices y cuándo aplicarlos puede marcar la diferencia entre una consulta que tarda minutos y una que se resuelve en milisegundos.

¿Qué es un índice y por qué es tan importante en SQL?

Un índice es una estructura auxiliar que el motor de base de datos almacena internamente. Funciona como una subconsulta precalculada que permite localizar registros de forma mucho más rápida cuando se ejecuta un query sobre la tabla correspondiente [0:15]. En lugar de recorrer toda la tabla fila por fila, SQL Server utiliza el índice para ir directamente a los datos que necesita.

Sin embargo, no todos los índices son necesarios ni todos mejoran el rendimiento. Cada caso debe analizarse de forma independiente antes de decidir si se crea, se modifica o incluso se elimina un índice existente [1:08].

¿Cómo impacta un índice en las lecturas lógicas y el consumo de memoria?

Al habilitar las estadísticas de consulta en SQL Server Management Studio, es posible observar métricas reveladoras. En el ejemplo analizado, una consulta sin índice realizaba la lectura de 507,233 páginas [1:35]. Cada página ocupa 8 KB, lo que significa que el motor estaba procesando aproximadamente 3 gigabytes de datos para resolver una sola consulta [3:05].

Después de crear el índice sugerido por el plan de ejecución, las lecturas lógicas se redujeron drásticamente:

Lecturas lógicas previas: 507,233 páginas (~3 GB).
Lecturas lógicas posteriores: apenas 3, 104 y 7 páginas respectivamente [3:25].
El servidor dejó de almacenar datos en tablas temporales de tempdb.

Esta reducción es insignificante para SQL Server en términos de esfuerzo, y en un sistema de producción con alta carga transaccional, puede traducirse en ahorro de horas de procesamiento [3:40].

¿Siempre hay que seguir las sugerencias del plan de ejecución?

El plan de ejecución de SQL Server a veces sugiere la creación de índices nuevos, pero no siempre es la acción correcta. En uno de los ejemplos, la consulta accedía a una sola tabla y aun así mostraba un join interno [4:15]. Esto ocurría porque el índice existente no incluía todas las columnas necesarias.

Al inspeccionar el ícono de Index Seek en el plan gráfico, se identificaron dos accesos:

El índice del foreign key ContactPersonID [4:40].
El índice del primary key de la tabla Sales Orders.

La solución no era crear un índice nuevo, sino modificar el índice existente agregando la columna faltante en la sección de columnas incluidas.

¿Cómo corregir un índice que no cubre todas las columnas necesarias?

Para optimizar el índice sin crear uno nuevo, se siguieron estos pasos:

Localizar la tabla en el explorador de objetos, en este caso Sales Orders [5:00].
Buscar el índice FK_Sales_Order_ContactPersonID con la herramienta gráfica.
Identificar la columna que quedaba fuera: PickingCompletedWhen [5:20].
Agregar esa columna en las columnas incluidas del índice, no en las columnas clave.
SQL Server reconstruye el índice automáticamente.

Tras la modificación, el plan de ejecución mostró una sola operación de búsqueda en lugar de dos, lo que mejoró el rendimiento de forma notable [5:55].

¿Cuándo crear un índice nuevo versus modificar uno existente?

El último ejemplo del archivo de práctica ilustra exactamente este dilema. SQL Server sugiere crear un índice en la tabla de facturas (Sales Invoices), pero la solución real es modificar el índice FK_Sales_Invoices_ContactPersonID y agregar la columna AccountsPersonID en la sección de columnas incluidas [6:30].

Este patrón se repite con frecuencia:

El plan de ejecución recomienda crear un índice.
Al analizar los índices existentes, se descubre que solo falta incluir una columna adicional.
Modificar es preferible a crear, porque cada índice nuevo consume espacio y puede afectar el rendimiento de las operaciones de escritura.

La clave está en analizar cada consulta de forma individual, revisar los índices ya existentes y tomar decisiones informadas. No basta con seguir ciegamente las recomendaciones del motor; entender el por qué detrás de cada sugerencia es lo que diferencia una optimización efectiva de una que genera problemas adicionales.

¿Has encontrado casos donde modificar un índice existente resolvió mejor el problema que crear uno nuevo? Comparte tu experiencia en los comentarios.

Resumen

¿Qué es un índice y por qué es tan importante en SQL?

¿Cómo impacta un índice en las lecturas lógicas y el consumo de memoria?

Después de crear el índice sugerido por el plan de ejecución, las lecturas lógicas se redujeron drásticamente:

Lecturas lógicas previas: 507,233 páginas (~3 GB).
Lecturas lógicas posteriores: apenas 3, 104 y 7 páginas respectivamente [3:25].
El servidor dejó de almacenar datos en tablas temporales de tempdb.

¿Siempre hay que seguir las sugerencias del plan de ejecución?

Al inspeccionar el ícono de Index Seek en el plan gráfico, se identificaron dos accesos:

El índice del foreign key ContactPersonID [4:40].
El índice del primary key de la tabla Sales Orders.

La solución no era crear un índice nuevo, sino modificar el índice existente agregando la columna faltante en la sección de columnas incluidas.

¿Cómo corregir un índice que no cubre todas las columnas necesarias?

Para optimizar el índice sin crear uno nuevo, se siguieron estos pasos:

Localizar la tabla en el explorador de objetos, en este caso Sales Orders [5:00].
Buscar el índice FK_Sales_Order_ContactPersonID con la herramienta gráfica.
Identificar la columna que quedaba fuera: PickingCompletedWhen [5:20].
Agregar esa columna en las columnas incluidas del índice, no en las columnas clave.
SQL Server reconstruye el índice automáticamente.

Tras la modificación, el plan de ejecución mostró una sola operación de búsqueda en lugar de dos, lo que mejoró el rendimiento de forma notable [5:55].

¿Cuándo crear un índice nuevo versus modificar uno existente?

Este patrón se repite con frecuencia:

El plan de ejecución recomienda crear un índice.
Al analizar los índices existentes, se descubre que solo falta incluir una columna adicional.
Modificar es preferible a crear, porque cada índice nuevo consume espacio y puede afectar el rendimiento de las operaciones de escritura.

¿Has encontrado casos donde modificar un índice existente resolvió mejor el problema que crear uno nuevo? Comparte tu experiencia en los comentarios.

Introducción al curso

Optimización Avanzada de SQL Server para Mejorar Rendimiento

Optimización de Consultas en SQL Server para Mejorar Rendimiento

Instalación de SQL Server y SQL Management Studio

Instalación de SQL Server y SQL Management Studio

Instalación de Bases de Datos AdventureWorks y Wide World Importers

Plan de Ejecución: Mejorando Consultas y Queries

Conociendo los índices

Función de los índices en bases de datos SQL

Optimización de Consultas SQL con Planes de Ejecución y Índices

Forzar Índices en Consultas SQL: Cuándo y Cómo Usarlos

Análisis de Índices en Consultas SQL: Beneficios y Limitaciones

Optimización de consultas

Uso del comando MERGE en SQL Server para operaciones complejas

Uso práctico de MERGE en procedimientos almacenados SQL

Creación y Uso de Triggers en Bases de Datos

Validación de Triggers en SQL: Insert y Update

Implementación de Triggers Administrativos en Bases de Datos

Validación de Datos con Constraints en SQL

Tablas Versionadas: Creación y Gestión de Historial de Cambios en SQL

Creación y uso de catálogos en Full Text Search

Queries más inteligentes

Creación y Uso de Funciones Tabla en SQL

Funciones Definidas por el Usuario en SQL

Creación y mantenimiento de vistas indexadas en SQL

Procedimientos Almacenados: Uso de JSON y XML en SQL Server

Diferencias entre tablas temporales y tablas variables en SQL

Optimización de base de datos

Configuración de Correos en SQL Server para Notificaciones

Reorganización y Programación de Índices en SQL Server

Estrategias de Respaldo y Mantenimiento de Bases de Datos

Gestión de Tamaño del Transaction Log en Planes de Mantenimiento

Configuración Óptima de la Base de Datos TempDB en SQL Server

Monitoreo

Uso de sp_who3 para Monitoreo en SQL Server

Consultas SQL para Monitoreo y Optimización de Bases de Datos

Conclusión

Optimización de Consultas y Rendimiento de Bases de Datos

Función de los índices en bases de datos SQL