DP-900: entender y usar índices en Azure SQL Database

João Barros 02 de August de 2026 6 min de lectura

Te enseñaré la competencia de comprender y aplicar índices en Azure SQL Database — un tema clave en "Datos relacionales en Azure" del DP-900. Saber cómo funcionan los índices importa tanto para responder a las preguntas conceptuales del examen como para optimizar consultas en la práctica. Aquí explico conceptos, doy ejemplos concretos y muestro cómo validar el impacto de un índice en el mundo real.

Qué necesitas saber

Un índice es una estructura que acelera la lectura de datos, similar al índice de un libro que apunta a páginas donde aparece un tema. En bases de datos relacionales como Azure SQL Database, los índices reducen el número de páginas de disco o bloques que el sistema tiene que leer para satisfacer una consulta. En términos prácticos, una consulta que antes realizaba 2 000 logical reads puede pasar a hacer 20 reads cuando se utiliza un índice adecuado — una reducción del 99% en el trabajo de lectura en algunos escenarios.

Ejemplo simple: una tabla Customers(id, name, city). Si escribes muchas consultas que filtran por city, crear un índice en city puede hacer que esas consultas sean mucho más rápidas porque el motor busca en el índice en lugar de leer la tabla completa (full table scan). Si la tabla tiene 1 millón de filas y cada página de disco contiene 8 KB, un full scan puede requerir miles de páginas leídas; un índice selectivo reduce ese número drásticamente.

Conceptos esenciales:

Clustered index: determina el orden físico de las filas en la tabla. Una tabla puede tener sólo un clustered index (por ejemplo: PRIMARY KEY por defecto). Elige una clave clustered que sea estrecha, estable y única siempre que sea posible (por ejemplo, un ID incremental).
Non-clustered index: estructura separada que mantiene punteros a las filas de la tabla; puedes tener varios por tabla. Pueden incluir columnas adicionales (INCLUDE) para crear un covering index.
Covering index: un índice que contiene todas las columnas necesarias para una consulta, evitando accesos adicionales a la tabla. Por ejemplo, un índice en (customer_id) INCLUDE (order_date, total) cubre una query que sólo devuelve esas columnas.
Selectividad: medida de cuán exclusiva es una columna. Columnas con alta selectividad (p. ej., > 10% de valores distintos en un conjunto grande) se benefician más de un índice; columnas con baja selectividad (p. ej., género con sólo M/F) rara vez ayudan.
Overhead: los índices aceleran lectura pero aumentan el coste en las operaciones de escritura (INSERT/UPDATE/DELETE) y consumen espacio. Como regla práctica, cada índice non-clustered puede añadir 20–50% al coste de almacenamiento dependiendo de las columnas incluidas.

Cómo funciona en la práctica

Aquí tienes un paso a paso práctico para crear y validar un índice en Azure SQL Database usando T-SQL. Supón que tienes una tabla Sales(order_id INT, customer_id INT, sale_date DATE, amount DECIMAL(10,2)).

-- 1. Criar um non-clustered index na coluna sale_date
CREATE INDEX IX_Sales_SaleDate
ON Sales(sale_date);

-- 2. Ver plano de execução para uma query que filtra por sale_date
SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT order_id, amount
FROM Sales
WHERE sale_date = '2025-01-15';

-- 3. Remover o índice se não for útil
DROP INDEX IX_Sales_SaleDate ON Sales;

Pasos a considerar para decidir crear un índice:

Identificar consultas frecuentes y columnas usadas en WHERE, JOIN, ORDER BY. Herramientas en Azure como Query Performance Insight e Intelligent Insights ayudan a ver las queries más costosas.
Evaluar la selectividad: si una columna tiene muchos valores repetidos, el índice puede no ser útil. Ej.: si el 90% de las filas tienen status = 'Active', un índice en status tendrá poco efecto.
Probar con y sin índice usando planes de ejecución, STATISTICS IO/TIME y medir logical reads. Observa métricas como tiempo de CPU y elapsed time; una mejora de 10–100x es común en casos ideales.
Monitorizar el impacto en las escrituras: los índices aumentan la latencia de INSERT/UPDATE/DELETE. En cargas de escritura intensiva, cada índice puede añadir 1–5% de overhead por operación, dependiendo de la complejidad.

Errores comunes

Indexar todas las columnas: crear demasiados índices (o índices en columnas poco selectivas) aumenta el overhead en las escrituras y ocupa espacio innecesario. En entornos OLTP, mantener 3–6 índices por tabla es habitual; >10 suele ser problemático.
Ignorar los planes de ejecución: crear índices sin analizar el plan puede no resolver el problema; el Query Optimizer decide si usa el índice. Un índice mal diseñado puede ni siquiera ser utilizado.
No mantener estadísticas: estadísticas desactualizadas llevan al Query Optimizer a elecciones subóptimas; recuerda UPDATE STATISTICS o configurar auto_update_statistics. En tablas grandes, una actualización de estadísticas puede mejorar drásticamente los planes.
Olvidar el mantenimiento: los índices se fragmentan con el tiempo; procedimientos de mantenimiento (REORGANIZE o REBUILD) deben planificarse. En tablas activas, un REBUILD semanal o mensual puede ser necesario, dependiendo de la fragmentación (p. ej., >30%).

Cómo practicar

Practica en Azure SQL Database con una base de datos de muestra (p. ej.: WideWorldImporters o AdventureWorks) y experimenta:

Crear/eliminar índices y comparar planes de ejecución. Observa logical_reads antes/después y apunta números concretos (ej.: de 2 500 a 150 reads).
Medir STATISTICS IO/TIME antes y después para cuantificar ganancias en I/O y tiempo de CPU.
Simular carga de escritura para observar el overhead: usa scripts que hagan miles de INSERT/UPDATE para medir latencia y throughput con y sin índice.

Nota: Azure SQL Database tiene funcionalidades de tuning automático que sugieren y aplican índices; revisa siempre las sugerencias y prueba antes de aplicar en producción. Para prepararte para el DP-900 usa el Practice Assessment OFICIAL (gratuito) de Microsoft y la study guide oficial (gratuita). Estos recursos te ayudan a verificar conocimientos en las áreas medidas por el examen sin recurrir a materiales prohibidos.

En resumen

Los índices aceleran lecturas; hay clustered y non-clustered, cada uno con trade-offs.
Elige columnas con alta selectividad y uso frecuente en filtros/join/order by. Considera incluir columnas con INCLUDE para crear covering indexes.
Prueba cambios con planes de ejecución y métricas (STATISTICS IO/TIME) y monitoriza el impacto en las escrituras.
Evita el exceso de índices, mantiene las estadísticas actualizadas y programa mantenimiento (REORGANIZE/REBUILD) para evitar fragmentación.