−98,3 %
Tiempo de respuesta: de 4 720 ms a 82 ms tras índice compuesto y reescritura sargable.
Demostración interactiva
Un caso real anonimizado: reporte de ventas sobre 42 millones de filas. Pulse el botón y vea, al mismo tiempo, cómo cambia la consulta, el plan de ejecución y la forma en que el motor recorre el índice.
Tiempo total: 4 720 ms · 42.1M filas leídas · 3.1 GB de I/O
Tiempo de respuesta: de 4 720 ms a 82 ms tras índice compuesto y reescritura sargable.
I/O lógico: el scan completo se convierte en un seek con búsqueda por rango.
Menos presión de CPU permitió bajar un escalón de instancia: ahorro directo en la factura cloud.
Bajo el capó
Un índice es un árbol balanceado. Cuando el predicado es sargable, el motor baja por el árbol y toca tres páginas. Cuando envolvemos la columna en una función, ese camino desaparece y no queda más remedio que leerlo todo.
fecha >= '2026-01-01' AND fecha < '2027-01-01' — el rango se resuelve dentro del índice.YEAR(fecha) = 2026 — la función se evalúa fila por fila.INCLUDE (total) el motor ni siquiera vuelve a la tabla.El diagrama de la derecha se sincroniza con la pestaña Antes / Después del laboratorio.
Nivel raíz, nivel intermedio y páginas hoja.
Table Scan: 12 de 12 particiones leídas.
Método
No hay magia ni un parámetro secreto: hay medición, hipótesis y verificación. Igual que en los ocho años anteriores.
Capturamos el plan real, las esperas del motor y el consumo de I/O. Sin línea base, cualquier mejora es una anécdota.
Agregar hardware esconde el problema un trimestre. Reescribir el predicado y diseñar el índice correcto lo resuelve.
El cambio se prueba con datos y volumen equivalentes, y se mide de nuevo antes de tocar producción.
Plan anterior, plan nuevo, milisegundos y costo. El informe queda con el cliente aunque el proyecto termine.
En la evaluación inicial identificamos las diez consultas que más recursos consumen y le mostramos el potencial de mejora de cada una.