Índices: la diferencia entre 3 segundos y 30 milisegundos

El orden de las columnas lo decide todo

SELECT id, total, cliente_id
FROM   pedidos
WHERE  sucursal_id = 12               -- igualdad
  AND  estatus     = 'ABIERTO'        -- igualdad
  AND  fecha      >= '2028-06-01'     -- rango
ORDER BY fecha DESC;
 
-- BIEN: igualdades primero, rango al final
CREATE INDEX IX_pedidos_suc_est_fecha
    ON pedidos (sucursal_id, estatus, fecha);
 
-- MAL: el rango va primero y bloquea el resto
CREATE INDEX IX_malo
    ON pedidos (fecha, sucursal_id, estatus);

Consecuencia útil

Un índice sobre (sucursal_id, estatus, fecha) también sirve para consultas que filtran solo por sucursal_id, o por sucursal_id y estatus. Por eso casi siempre puedes consolidar tres índices en uno bien ordenado, en lugar de crear uno por consulta.

Índices que cubren la consulta

CREATE INDEX IX_pedidos_suc_est_fecha
    ON pedidos (sucursal_id, estatus, fecha)   -- llave: para buscar y ordenar
    INCLUDE (total, cliente_id, vendedor_id);  -- incluidas: para no ir a la tabla
 
-- PostgreSQL 11+ soporta la misma sintaxis INCLUDE.
-- En MySQL/InnoDB no existe INCLUDE: se agregan a la llave,
-- con el costo de tamaño que eso implica.

Hasta dónde cubrir

Es tentador incluir todas las columnas de la tabla y acabar con una copia completa que hay que mantener en cada escritura. Cubre las consultas frecuentes y de pocas columnas. Si una consulta necesita quince columnas, probablemente el Key Lookup no sea el problema real.

Lo que impide usar un índice que sí existe

-- 1. Función sobre la columna
WHERE YEAR(fecha) = 2028                         ✗ recorre todo
WHERE fecha >= '2028-01-01' AND fecha < '2029-01-01'   ✓
 
-- 2. Conversión de tipo
WHERE CONVERT(varchar, cliente_id) = '8841'      ✗
WHERE cliente_id = 8841                          ✓
 
-- 3. Comodín al inicio
WHERE nombre LIKE '%lopez%'                      ✗
WHERE nombre LIKE 'lopez%'                       ✓
 
-- 4. Cálculo del lado de la columna
WHERE total * 1.16 > 5000                        ✗
WHERE total > 5000 / 1.16                        ✓

La trampa silenciosa

La conversión implícita entre varchar y nvarchar, o entre texto y número, no genera error ni advertencia: solo hace que el índice deje de usarse. Es habitual cuando el ORM manda parámetros con un tipo distinto al de la columna. Si un índice «no se usa sin razón», revisa los tipos primero.

Cuando la función es inevitable

Si de verdad necesitas filtrar por una expresión, la mayoría de los motores permiten indexarla: columnas calculadas persistidas e indexadas en SQL Server, índices sobre expresiones en PostgreSQL. Es mejor que reescribir media aplicación.

El costo que nadie mira: escribir

Referencia práctica

En tablas muy transaccionales, más de cinco o seis índices no agrupados empieza a ser señal de revisión —no una prohibición, una señal—. En tablas de consulta o histórico puedes tener más sin problema, porque casi no se escriben. Y siempre revisa el reporte de escrituras contra lecturas antes de agregar uno más.

Duplicados y redundantes

SELECT OBJECT_NAME(i.object_id) AS tabla,
       i.name                    AS indice,
       STUFF((SELECT ', ' + c.name
              FROM   sys.index_columns ic
              JOIN   sys.columns c
                     ON  c.object_id = ic.object_id
                     AND c.column_id = ic.column_id
              WHERE  ic.object_id = i.object_id
                AND  ic.index_id  = i.index_id
                AND  ic.is_included_column = 0
              ORDER BY ic.key_ordinal
              FOR XML PATH('')), 1, 2, '')  AS columnas_clave
FROM   sys.indexes i
WHERE  i.type_desc = 'NONCLUSTERED'
  AND  OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
ORDER BY tabla, columnas_clave;

Qué buscar en el resultado

Ordenado así, los redundantes quedan juntos y saltan a la vista: cliente_id junto a cliente_id, fecha junto a cliente_id, fecha, estatus. El de más columnas suele absorber a los otros dos. Antes de eliminarlos, verifica que ninguno sea único ni respalde una restricción.

Los índices que nadie lee

SELECT OBJECT_NAME(i.object_id)  AS tabla,
       i.name                     AS indice,
       ISNULL(us.user_seeks,0) + ISNULL(us.user_scans,0)
       + ISNULL(us.user_lookups,0) AS lecturas,
       ISNULL(us.user_updates,0)   AS escrituras
FROM   sys.indexes i
LEFT JOIN sys.dm_db_index_usage_stats us
       ON  i.object_id = us.object_id
       AND i.index_id  = us.index_id
       AND us.database_id = DB_ID()
WHERE  i.type_desc = 'NONCLUSTERED'
  AND  OBJECTPROPERTY(i.object_id, 'IsUserTable') = 1
ORDER BY lecturas ASC, escrituras DESC;

Antes de borrar, verifica el periodo

Estas estadísticas se reinician cuando reinicia el servicio. Si el servidor se reinició la semana pasada, un índice con cero lecturas puede ser el que usa el cierre mensual. Confirma desde cuándo se acumulan y, ante la duda, deshabilita el índice en lugar de eliminarlo: si algo se rompe, se rehabilita en segundos; si lo borraste, hay que reconstruirlo y en tablas grandes eso duele.

Revisión de índices, tabla por tabla

Imprimir o guardar como PDF

¿Tienes una tabla con doce índices y nadie sabe cuáles sirven?

Hacemos la revisión completa: capturamos las consultas reales, medimos la línea base, consolidamos el conjunto de índices al mínimo necesario y verificamos que las escrituras no se degradaron. Te entregamos el antes y el después en lecturas lógicas, que es la única medida que no miente.

• —Optimización de índices y consultas
• —Diagnóstico de rendimiento en SQL Server y PostgreSQL
• —Mantenimiento gestionado de bases de datos
• —Observabilidad para aplicaciones .NET

Diagnóstico inicial sin costo sobre una de tus tablas críticas. Te entregamos los hallazgos aunque no nos contrates.