Definición
Un índice es una estructura que la base de datos mantiene aparte de la tabla para poder localizar filas rápido, sin tener que leerlas todas.
La analogía del libro es exacta y por una vez no engaña. Para encontrar todas las menciones de una palabra en un libro de 800 páginas tienes dos opciones: leerlo entero, o ir al índice del final, buscar la palabra y saltar directamente a las páginas que indica. El índice ocupa páginas extra y hay que rehacerlo si el libro cambia, pero la búsqueda pasa de horas a segundos.
En una base de datos es igual: sin índice, el motor hace un recorrido completo de la tabla. Con índice, salta directo a las filas que cumplen la condición.
Cómo funciona
La mayoría de índices son árboles B, una estructura ordenada que permite descartar la mitad de los candidatos en cada paso. Buscar en un millón de filas cuesta unas veinte comparaciones en vez de un millón.
Lo que hay que entender para usarlos bien:
Se indexan columnas, no tablas. Creas un índice sobre pedidos.cliente_id porque filtras por ahí.
El orden importa en los índices compuestos. Un índice sobre (cliente_id, fecha) sirve para filtrar por cliente, y también para filtrar por cliente y fecha. No sirve para filtrar solo por fecha. Es como buscar en la guía telefónica por nombre de pila: está ordenada por apellido.
No siempre se usan. Si tu condición envuelve la columna en una función —WHERE YEAR(fecha) = 2026— el motor no puede usar el índice de fecha. Hay que escribirlo como un rango: WHERE fecha >= '2026-01-01' AND fecha < '2027-01-01'.
La clave primaria ya lleva índice. Y las columnas UNIQUE también.
Ejemplo práctico
En el CRM de IMDICA teníamos un informe de ventas por cliente que tardaba catorce segundos. Con los usuarios esperando delante de la pantalla, eso es inaceptable.
La consulta no estaba mal escrita. El problema era que filtraba por cliente_id en la tabla de líneas de pedido, que tiene cientos de miles de filas, y esa columna no tenía índice. El motor recorría la tabla entera en cada informe.
Crear un índice sobre esa columna: de catorce segundos a cuarenta milisegundos. Trescientas cincuenta veces más rápido, con una línea de SQL y sin tocar el código de la aplicación.
La herramienta que lo diagnostica es EXPLAIN delante de la consulta. Te dice si el motor va a usar un índice o va a recorrerlo todo. Si ves un recorrido completo sobre una tabla grande, ahí está tu problema.
El detalle que aprendí después: no todo se arregla creando índices. Añadimos unos cuantos "por si acaso" en tablas donde se escribe mucho, y las inserciones se ralentizaron. Cada índice hay que actualizarlo en cada INSERT, UPDATE y DELETE. Los quitamos.
Qué indexar
- Columnas por las que filtras en el
WHEREcon frecuencia. - Claves foráneas. Casi siempre merecen índice, porque es por donde se hacen los
JOIN. Algunos motores no lo crean solos. - Columnas por las que ordenas si el conjunto es grande.
- Columnas de búsqueda de texto, con un índice de texto completo específico.
Qué NO indexar
- Columnas con muy pocos valores distintos. Un índice sobre un campo que solo vale "sí" o "no" apenas descarta nada: el motor lo ignorará.
- Tablas pequeñas. Con doscientas filas, leerlas todas es más rápido que consultar un índice.
- Tablas donde se escribe muchísimo y se lee poco. Cada índice encarece cada escritura.
- Todo por si acaso. Es el error más frecuente. Un índice ocupa espacio, ralentiza las escrituras y hay que mantenerlo.
Errores comunes
- Crear índices sin medir antes. Ejecuta
EXPLAIN, mira dónde está el problema real y crea el índice que hace falta. - Duplicarlos. Si tienes uno sobre
(a, b), el de soloasobra: el compuesto ya lo cubre. - Envolver la columna en una función en el
WHEREy anular el índice sin darte cuenta. - Olvidarlos al migrar. Un volcado y restauración puede no traerse los índices, y de repente producción va lentísima sin que nada haya cambiado en el código.
- Creerlos gratis. Espacio en disco, escrituras más lentas y mantenimiento. Compensan casi siempre, pero cuestan.
Cuándo mirarlo
Cuando una consulta tarde más de lo razonable. Antes de reescribir código, antes de meter caché y mucho antes de contratar un servidor más grande, mira si hay un índice que falta. Es la optimización más barata y más rentable que existe en el trabajo con datos.
