Indexación
Un índice es como el índice al final de un libro: le permite a la saltar directamente a las filas coincidentes en lugar de escanear cada una. Sin índices, las consultas se vuelven más lentas a medida que los datos crecen: está bien con 100 filas, es doloroso con 1.000.000.
Sin un índice, la base de datos revisa cada fila una por una; con uno, salta directamente a la coincidencia, de la misma forma que el índice de un libro te envía a la página correcta en lugar de leerlo de principio a fin:
NO INDEX (Seq Scan) WITH INDEX (Index Scan)
read EVERY row, one by one jump straight to matches
┌─────────────────────┐ ┌─────────────┐
│ row 1 ✗ │ │ INDEX │
│ row 2 ✗ │ │ author_id │
│ row 3 ✓ match │ ◀──────┐ │ ──┬── │
│ row 4 ✗ │ │ └─────┼───────┘
│ ... (1,000,000) │ │ ▼
│ row N ✓ match │ └──▶ rows 3, 998 ✓
└─────────────────────┘ a few hops, not a million
Las pautas prácticas:
- Indexa las columnas por las que filtras o haces join con frecuencia (p. ej.
author_id,email). - Las claves primarias se indexan automáticamente.
- No indexes todo: cada índice acelera las lecturas pero ralentiza las escrituras y ocupa espacio.
- Añade índices cuando veas una consulta lenta, no de forma preventiva para cada columna.
La forma honesta de averiguar si un índice ayuda es preguntarle a la base de datos, no adivinar. Todo motor tiene EXPLAIN (en Postgres, EXPLAIN ANALYZE), que muestra el plan que va a usar:
EXPLAIN ANALYZE
SELECT * FROM posts WHERE author_id = '...';
Si la salida dice Seq Scan en una tabla grande, la base de datos está leyendo cada fila, una señal de que un índice ayudaría. Después de añadir uno, debería cambiar a un Index Scan. Esta es una tarea excelente para delegar a la IA: pega la consulta lenta y la salida de EXPLAIN, y pregunta qué índice añadir y por qué. Te mantienes en control comprendiendo la respuesta, no memorizando la teoría de índices.