Cómo elegir el tipo de índice adecuado

Ya nos metimos en la teoría de los índices, conocimos sus tipos, aprendimos a crearlos y borrarlos, y también vimos cómo indexar tipos de datos complejos como arrays y JSONB. Ahora toca hablar de cómo elegir justo ese índice que va a funcionar bien para tus tareas — porque si eliges mal, puedes acabar con un buen lío.

Imagina que tu base de datos es una biblioteca y las consultas son visitantes buscando libros. Si los libros están tirados por el suelo, buscar algo se vuelve un paseo eterno. Los índices son como estanterías y catálogos bien organizados que te ayudan a encontrar lo que buscas sin perder tiempo revisando todo.

Pero si pones la estantería o el catálogo equivocado, por ejemplo, usas un índice HASH donde necesitas buscar por rango, es como si el bibliotecario intentara buscar libros por título pero solo tuviera un catálogo por año de publicación — el proceso se alarga y todos empiezan a quejarse. En la base de datos, esto se traduce en consultas lentas y más carga para el sistema.

Hoy vamos a ver cómo elegir el índice correcto para que tus consultas vuelen y la base no se canse. Si no, el resultado será un desastre: las consultas van lentas, los recursos se consumen y el bibliotecario (PostgreSQL) acaba deprimido.

Criterios para elegir un índice: checklist

Cuando vayas a elegir un índice, respóndete estas preguntas:

1. ¿Qué tipo de datos tienes en esa columna?
   • Por ejemplo, números INTEGER, FLOAT suelen ir bien con un índice B-TREE, arrays — GIN, campos de texto — eso ya depende más de la tarea.

2. ¿Qué consultas haces más a menudo?

   • WHERE field = value? ¿Búsqueda directa? Seguramente te sirve B-TREE o HASH.
   • ¿Buscas en arrays o JSONB? Mira hacia GIN.
   • ¿Datos geo, rangos? Piensa en GiST.

3. ¿Qué pasa con tus datos?

   • Si tienes una tabla con muchas inserciones y actualizaciones, evita indexar de más, porque eso mete sobrecarga.

4. ¿Necesitas garantizar unicidad?

   • En ese caso tendrás que usar un índice con el atributo UNIQUE.

Casos: ejemplos reales de elección de índice

Vamos a ver algunos escenarios reales.

1. Búsqueda simple por igualdad

Trabajas con una base de datos de estudiantes y quieres encontrar rápido a un estudiante por su email:

SELECT * FROM students WHERE email = 'student@example.com';

¿Qué es importante aquí? Buscamos por igualdad. La mejor opción es un índice B-TREE, porque va genial para búsquedas de coincidencia exacta.

CREATE INDEX idx_students_email ON students (email);

O, si el email debe ser único:

CREATE UNIQUE INDEX idx_students_email_unique ON students (email);

2. Búsqueda por rango

Ahora imagina que quieres encontrar estudiantes mayores de 18 años:

SELECT * FROM students WHERE age > 18;

Para búsquedas por rango, B-TREE también va perfecto, porque su estructura está hecha para búsquedas ordenadas.

CREATE INDEX idx_students_age ON students (age);

3. Filtrado por arrays

Tienes una tabla courses, donde una columna guarda un array con los IDs de los estudiantes apuntados al curso. Quieres encontrar todos los cursos donde está apuntado el estudiante con ID 123.

SELECT * FROM courses WHERE student_ids @> ARRAY[123];

Para este tipo de consultas, el índice GIN es ideal, porque está optimizado para trabajar con arrays.

CREATE INDEX idx_courses_students_ids ON courses USING gin (student_ids);

4. Extracción de datos de JSONB

Supón que tienes una tabla con datos en JSONB, donde guardas info de pedidos. Quieres encontrar todos los pedidos donde el cliente es de la ciudad "Moscow":

SELECT * FROM orders WHERE data->>'city' = 'Moscow';

Aquí va bien el índice GIN, que permite buscar de forma eficiente por claves y valores en JSONB.

CREATE INDEX idx_orders_data ON orders USING gin (data);

5. Datos geográficos

Si trabajas con información geográfica, por ejemplo, quieres encontrar todos los puntos dentro de un radio dado, usa el índice GiST. Este tipo de índice va genial con geometría y rangos.

CREATE INDEX idx_locations_geom ON locations USING gist (geom);

Comparación de rendimiento de diferentes índices

Vamos con un ejemplo real buscando estudiantes por email. La tabla tiene 1 millón de registros. Probamos la consulta con diferentes índices y sin índice:

Conclusión: en este caso, usar un índice B-TREE hace que la consulta sea más de 500 veces más rápida.

Errores al elegir índices

El error más común es crear índices "por si acaso". Por ejemplo, decides indexar cada columna de tu tabla, pero luego ves que las inserciones van mucho más lentas. Recuerda, un índice no es una varita mágica que siempre funciona. Es una herramienta potente en buenas manos, pero si la usas mal, puede ser peor.

Otro error típico es elegir el tipo de índice equivocado. Por ejemplo, usas un índice HASH para búsquedas por rango y tus consultas de repente van lentísimas. Todo porque el índice HASH solo sirve para búsquedas exactas.

Recomendaciones para elegir un índice

• Si haces búsquedas por igualdad o por orden a menudo, usa B-TREE.
• Para coincidencias exactas y ahorrar memoria, puedes usar HASH.
• Si trabajas con arrays o JSONB, tu opción es GIN.
• Para rangos o datos geográficos, usa GiST.

Y por último, el consejo clave: ¡no te olvides de analizar tus consultas! Usa el comando EXPLAIN y EXPLAIN ANALYZE para ver cómo PostgreSQL usa los índices y qué puedes mejorar.

EXPLAIN ANALYZE
SELECT * FROM students WHERE email = 'student@example.com';

¡Y eso es todo por hoy! Ahora tienes el conocimiento para elegir índices como un jedi elige su sable de luz. Ve con cuidado, no crees índices donde no hacen falta y revisa siempre cómo afectan al rendimiento.