Mejores Prácticas de Estadísticas
La calidad del planificador depende de estadísticas actualizadas. Trata ANALYZE como parte de cada migración de datos y revisión de rendimiento en PostgreSQL 18.4.
Cómo Usar Esta Lista
- Ejecutar después de DML masivo antes de indexar índices para benchmarking.
- Emparejar con verificaciones de estimación vs. filas reales de
EXPLAIN. - Documentar estadísticas extendidas en PRs de migración cuando se añadan.
A - Cadencia de Actualización
-
ANALYZEmanual después deCOPYmasivo, purgas de borrado o rellenado. Autoanalyze puede tener un retraso de horas. - Analizar nuevas particiones cuando se adjunten. Las estadísticas vacías engañan a la poda.
- Reanalizar después de
CREATE INDEX CONCURRENTLYen tablas enormes. Confirmar que el planificador lo elige. - Monitorizar
n_mod_since_analyzeen tablas activas. Alerta antes de que los planes se deterioren. - Incluir el paso de análisis en los runbooks de ETL. Último trabajo antes de que abra BI.
B - Profundidad y Correlación
- Aumentar el objetivo de
STATISTICSsolo en columnas con sesgo demostrado. No globalmente por defecto. - Añadir estadísticas extendidas para filtros
ANDcorrelacionados. Dependencias o ndistinct según corresponda. - Crear estadísticas de expresiones para predicados de informes inmutables.
date_trunc,lowerdonde estén indexados. - Validar con
pg_statsy EXPLAIN antes/después. Demostrar correcciones de estimación. - Eliminar estadísticas extendidas no utilizadas para acortar el análisis. Auditoría periódica del catálogo.
C - Seguridad de Operaciones
- Nunca deshabilitar autovacuum/analyze globalmente. Ajuste por tabla en su lugar.
- Programar análisis pesados fuera de horas pico cuando sea posible. Las tablas grandes todavía se muestrean intensamente.
- Mantener estadísticas en repositorios de migración lógicos.
CREATE STATISTICSes esquema. - Probar planes como roles de aplicación con GUCs de producción.
random_page_costa nivel de rol importa. - Capturar datos enmascarados a escala de producción para revisión de planes. Bases de datos de desarrollo vacías mienten.
D - Proceso de Equipo
- Rechazar PRs de índices sin planes post-análisis. Prevenir falsos negativos.
- Rastrear regresiones de planes en CI con líneas base JSON EXPLAIN. Detección de deriva de estadísticas.
- Documentar supuestos de sesgo de inquilino en ADRs. Índices parciales más pares de estadísticas.
- Entrenar a los equipos de aplicaciones: el despliegue de ORM no es analizar. El cambio de datos activa la notificación de DBA.
- Revisar pg_stat_user_tables mensualmente en las 20 tablas principales. Higiene operativa.
Preguntas Frecuentes
¿Cuánto tiempo después de ETL analizar?
Antes de que cualquier tráfico de usuario o BI acceda a los nuevos datos.¿El objetivo de estadísticas por defecto es suficiente?
A menudo para columnas uniformes; raramente para enumeraciones de estado con sesgo.¿Analizar todas las columnas o algunas?
Orientar columnas cambiadas o sesgadas para ahorrar tiempo.¿Estadísticas en standby?
Las réplicas heredan las estadísticas primarias; el análisis se ejecuta en el primario.Seguridad de pg_stats?
Puede revelar la distribución; restringir entornos sensibles.Factor de escala de autovacuum analyze?
Bajo en tablas de hechos activas (0.01-0.02).¿Cuándo son obligatorias las estadísticas extendidas?
Cuando los filtros AND subestiman por órdenes de magnitud después del análisis.Autovacuum en la nube?
Existen preajustes administrados; aún así ajustar por tabla para hechos.Histograma vs índice?
Las estadísticas guían los planes; los índices habilitan las rutas.Siguiente sección?
Mantenimiento del diseño de índices para las estructuras físicas que las estadísticas deberían usar.Relacionados
- Estadísticas Básicas - Fundamentos del catálogo
- ANALYZE y Autoanalyze - Tiempos
- Estadísticas Extendidas - Herramientas de correlación
- Mejores Prácticas de EXPLAIN - Captura de planes
Versiones de la pila: 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+.