Tienes una tabla con un millón de registros y una consulta que tarda varios segundos. Añades un índice sobre la columna del filtro y de pronto responde al instante. Parece magia, pero es una idea sencilla que ya conocías antes de tocar una base de datos.
La analogía del libro
Imagina un manual de 800 páginas y la necesidad de encontrar todo lo que dice sobre “normalización”. Sin ayuda, tendrías que leer página por página hasta el final, porque el tema podría reaparecer en cualquier parte. Eso es lo que la base de datos llama un recorrido completo de tabla.
Ahora imagina que el libro tiene un índice alfabético al final. Buscas la palabra, encuentras “normalización: 145, 312, 588” y vas directo a esas tres páginas. Eso es un índice en el sentido de base de datos: una estructura auxiliar, ordenada, que apunta a la ubicación real de los datos.
La analogía también revela los costos. El índice ocupa páginas adicionales del libro, y si alguien reescribe un capítulo hay que actualizarlo. Exactamente lo mismo ocurre en una base de datos.
Cómo funciona por dentro
La mayoría de los motores relacionales —PostgreSQL, MySQL, SQL Server, Oracle— usan por defecto una estructura llamada árbol B (o su variante B+). No hace falta implementarla, pero entender su comportamiento explica casi todo lo demás.
La idea es que los valores se guardan ordenados en una estructura jerárquica de pocos niveles. Buscar un valor consiste en descender por el árbol descartando en cada paso la mayor parte de los candidatos, igual que al buscar una palabra en un diccionario: abres por la mitad, decides si vas hacia adelante o hacia atrás, y repites.
El efecto práctico es enorme. Duplicar el tamaño de la tabla apenas añade trabajo a una búsqueda por índice, mientras que el recorrido completo se duplica también. Por eso la diferencia se vuelve dramática justo cuando los datos crecen.
Como los valores quedan ordenados, el índice también sirve para rangos (BETWEEN, >, <) y para evitar ordenamientos costosos en un ORDER BY.
Qué columnas conviene indexar
No todas las columnas se benefician igual. Estas son las candidatas naturales:
- Claves primarias. Prácticamente todos los motores las indexan automáticamente.
- Claves foráneas. Son las columnas que usan los
JOIN, y sin índice cada unión puede volverse muy costosa. - Columnas usadas en
WHEREcon frecuencia, sobre todo si filtran mucho. - Columnas de
ORDER BYen consultas que se ejecutan a menudo. - Columnas con restricción de unicidad, como un correo electrónico o un documento de identidad.
El concepto de selectividad
Aquí está la idea que separa un índice útil de uno inútil. La selectividad mide cuántos valores distintos tiene una columna en relación con el total de filas.
| Columna | Valores distintos | Selectividad | ¿Índice útil? |
|---|---|---|---|
| documento_identidad | Casi todos únicos | Muy alta | Sí |
| correo_electronico | Casi todos únicos | Muy alta | Sí |
| ciudad | Cientos | Media | Normalmente sí |
| estado_pedido | Cinco o seis | Baja | Rara vez |
| activo (sí/no) | Dos | Muy baja | Casi nunca |
La lógica es intuitiva: si filtrar por una columna booleana devuelve la mitad de la tabla, el motor concluye que es más rápido leer toda la tabla de corrido que saltar de un lado a otro siguiendo punteros. Por eso puede ignorar un índice que tú creaste con buena intención.
Índices compuestos y el orden de las columnas
Un índice puede abarcar varias columnas a la vez. Aquí el orden importa muchísimo y es fuente de confusión frecuente.
Un índice sobre (pais, ciudad, codigo_postal) se comporta como una guía telefónica ordenada primero por país, luego por ciudad y luego por código postal. Con esa estructura puedes buscar eficientemente:
- Por
paissolamente. - Por
paisyciudad. - Por las tres columnas juntas.
Pero no puedes usarlo eficientemente para buscar solo por ciudad, igual que no podrías usar una guía telefónica ordenada por apellido para encontrar a todos los que se llaman “Carlos”. Esta regla se conoce como el principio del prefijo izquierdo.
El precio que se paga
Si los índices solo tuvieran ventajas, se indexaría todo. No es así.
- Escrituras más lentas. Cada
INSERT,UPDATEoDELETEobliga a actualizar todos los índices afectados. Una tabla con ocho índices paga ese costo ocho veces. - Espacio en disco. Un índice puede ocupar una fracción considerable del tamaño de la tabla, y varios índices suman rápido.
- Memoria. Los índices compiten por la caché con los propios datos.
- Mantenimiento. Con el tiempo pueden fragmentarse y requerir reconstrucción.
Por eso un sistema con muchísimas escrituras y pocas lecturas necesita una estrategia de indexación distinta a un sistema de informes que casi solo consulta.
Cuándo el índice no se usa aunque exista
Este es un punto que frustra a mucha gente: el índice está creado, pero la consulta sigue lenta. Suele deberse a alguna de estas causas.
- La columna está dentro de una función. Escribir
WHERE YEAR(fecha) = 2026impide usar el índice sobrefecha. Conviene reescribirlo como un rango:WHERE fecha >= '2026-01-01' AND fecha < '2027-01-01'. - Comodín al inicio.
LIKE '%texto'no puede aprovechar el orden del índice, mientras queLIKE 'texto%'sí. - Conversión implícita de tipos. Comparar una columna numérica con un texto suele anular el índice.
- Estadísticas desactualizadas. El planificador decide en función de estimaciones; si están obsoletas, toma malas decisiones.
Cómo verificarlo
No hace falta adivinar. Todos los motores ofrecen una forma de mostrar el plan de ejecución: EXPLAIN en MySQL y PostgreSQL, EXPLAIN ANALYZE para ejecutarlo realmente y medir, o el plan gráfico en SQL Server.
Lo que interesa es distinguir si el motor recorre la tabla completa o usa un índice. Una buena práctica es medir antes y después de crear el índice, en lugar de asumir que ayudó.
Una recomendación práctica
Empieza con lo mínimo: claves primarias y foráneas. Deja que el sistema funcione, identifica las consultas realmente lentas y crea índices para resolver esos casos concretos, midiendo el resultado. Indexar “por si acaso” tiende a generar tablas cargadas de índices que nadie usa pero que todos pagan en cada escritura.
Si quieres profundizar en modelado, SQL y optimización, en Cursa encontrarás cursos gratuitos de bases de datos que cubren desde el diseño de tablas hasta el ajuste de consultas.
