Mejores Prácticas de Mantenimiento de Índices

Los índices son contratos que afectan a las escrituras. Mantenlos con evidencia de planes, estadísticas de uso y métricas de hinchazón en PostgreSQL 18.4.

Cómo Usar Esta Lista

• Requerir prueba EXPLAIN en las PR de índices.
• Revisar idx_scan trimestralmente en tablas con muchas escrituras.
• Emparejar cambios de índice con ANALYZE en la misma ventana de cambio.

A - Puertas de Diseño

• Mapear el índice a una forma de consulta específica en el ticket. No crear índices especulativos.
• Preferir índices compuestos sobre muchos índices de una sola columna. Reducir la amplificación de escrituras.
• Poner columnas de igualdad antes que columnas de rango en los compuestos. Disciplina de prefijo izquierdo.
• Usar índices parciales para predicados selectivos estables. Más pequeños, más rápidos, escrituras más baratas.
• Evitar indexar booleanos de baja cardinalidad solos. A menos que el predicado parcial sea una porción pequeña.

B - Operaciones

• Usar CREATE INDEX CONCURRENTLY en migraciones de producción. Evitar bloqueos largos de escritura.
• Ejecutar ANALYZE después de la creación del índice en tablas grandes. Comprobación de adopción por el planificador.
• Monitorizar pg_stat_user_indexes.idx_scan antes de las eliminaciones. Limpieza basada en evidencia.
• REINDEX CONCURRENTLY cuando la hinchazón esté probada, no solo por horario. Reconstrucciones dirigidas.
• Rastrear el crecimiento del tamaño del índice frente al tamaño de la tabla. Detección temprana de hinchazón.

C - Flujo de Trabajo del Equipo

• Documentar las solicitudes de índice rechazadas con EXPLAIN. Prevenir debates repetidos.
• Auditar prefijos redundantes después de añadir compuestos. Eliminar índices obsoletos.
• Incluir DROP CONCURRENTLY de reversión en la migración. Ruta de reversión segura.
• Probar la carga de escrituras después de paquetes de índices. Medir el impacto en p95 de inserción.
• Alinear con los estándares de revisión de consultas para el texto SQL. El SQL oculto por ORM sigue siendo revisado.

D - Antipatrones

• No indexar todas las claves foráneas ciegamente si no se usan. Indexar las uniones de hijos que ejecutas.
• No duplicar la restricción UNIQUE con un índice normal. Desorden en el catálogo.
• No añadir GIN en JSONB sin consultas de contención. Enorme coste de mantenimiento.
• No corregir escaneos secuenciales con índices antes de ANALYZE. Estadísticas primero.
• No dejar índices INVÁLIDOS después de un CONCURRENTLY fallido. Eliminar y reintentar.

Preguntas Frecuentes

Relacionados

• Conceptos Básicos de Diseño de Índices - Reglas de diseño
• Índices Duplicados y Redundantes - Auditorías
• REINDEX y REINDEX CONCURRENTLY - Reconstrucciones
• Manejo de Solicitudes de Índices - Proceso del equipo

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, y PostGIS 3.5+.