Decisión: ¿qué tipo de índice?
El tipo de índice adecuado depende del patrón de acceso de la consulta (igualdad, rango o búsqueda de texto/JSON), de la cardinalidad de la columna y del equilibrio entre lecturas y escrituras. Un índice equivocado desperdicia espacio y además ralentiza las escrituras. Este árbol parte de la forma de la consulta y le orienta entre las opciones B-tree, Hash, Bitmap, GIN/GiST, parcial y covering, y le recuerda que el orden de las columnas es crítico en un índice compuesto.
¿Cómo usa su consulta esta columna?
El patrón de acceso es el factor más decisivo al elegir un índice. ¿Solo compara la columna con '=', hace rangos/ordenaciones (>, <, BETWEEN, ORDER BY), o busca en texto completo, en un campo JSON o en datos geométricos/arrays? Empiece aquí; no elija un tipo de índice hasta que la necesidad esté clara.
- Igualdad y rango/ordenación combinados (=, >, <, BETWEEN, ORDER BY)
- Solo igualdad (=), sin rango ni ordenación
- Búsqueda de texto completo, campo JSON/JSONB, array o geométrica
- La consulta siempre apunta al mismo subconjunto pequeño de filas (p. ej. WHERE status='active')
¿Cuál es la cardinalidad de la columna (número de valores distintos)?
Si se necesita rango/ordenación, el valor por defecto es B-tree; sin embargo, para columnas con muy pocos valores distintos (cardinalidad baja: sexo, estado, sí/no) en un data warehouse con lectura intensiva, un índice Bitmap puede ser mejor. ¿La columna tiene muchos valores únicos o unos pocos valores repetidos?
- Cardinalidad alta (muchos valores únicos) o carga OLTP
- Cardinalidad baja y lectura intensiva / data warehouse (DWH)
¿La consulta lee solo las columnas del índice?
El patrón de acceso se ajusta a un B-tree. Una última optimización: si todas las columnas que la consulta devuelve y por las que filtra están en el índice, el motor puede responder solo desde el índice sin visitar la tabla (index-only / covering scan). ¿Su consulta lee unas pocas columnas o necesita la mayor parte de la fila?
- Sí, unas pocas columnas; se puede responder sin visitar la tabla
- No, basta con el acceso estándar
Recomendación: B-tree (por defecto)
Un B-tree es una estructura de árbol equilibrado que admite una amplia gama de patrones de acceso: igualdad, rango, ordenación (ORDER BY), coincidencia de prefijo con LIKE 'abc%' y MIN/MAX. Es el tipo de índice por defecto en la mayoría de los motores relacionales y el punto de partida correcto en caso de duda.
Recomendación: índice Hash (solo igualdad)
Un índice hash almacena el hash del valor de la columna y es muy rápido solo para búsquedas de igualdad exacta ('='). No admite búsquedas por rango, ordenación ni prefijo, por lo que su caso de uso es limitado.
Recomendación: índice Bitmap (cardinalidad baja / DWH)
Un índice bitmap mantiene un array de bits para cada valor distinto y combina muy rápidamente varias condiciones de cardinalidad baja con AND/OR a nivel de bits. Es potente en cargas con lectura intensiva como data warehousing e informes.
Recomendación: GIN / GiST (texto, JSON, array, geometría)
PostgreSQL tiene familias de índices especializadas para tipos de acceso que un B-tree estándar no puede gestionar. GIN apunta a muchos componentes dentro de un valor (palabras, claves JSONB, elementos de array); GiST se adapta a consultas geométricas/de rango/de vecino más cercano.
Recomendación: índice parcial / filtrado
Un índice parcial indexa solo las filas que cumplen una condición (WHERE ...) en lugar de toda la tabla. Si las consultas siempre apuntan al mismo subconjunto pequeño, el índice se vuelve mucho más pequeño y rápido, y el costo de escritura baja.
Recomendación: índice covering (INCLUDE)
Un índice covering contiene todas las columnas que necesita la consulta, lo que permite al motor responder solo desde el índice sin visitar la tabla (heap) en absoluto (index-only scan). Ofrece una aceleración considerable en consultas que se ejecutan con frecuencia y devuelven pocas columnas.