EXPLAIN Melhores Práticas
Capturar planos de forma rigorosa transforma adivinhação em evidência revisável. Use esta lista ao triar consultas lentas ou aprovar PRs de índices no PostgreSQL 18.4.
Como Usar Esta Lista
- Cole a saída completa de
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)em tickets. - Sempre capture antes e depois das mudanças no mesmo conjunto de dados.
- Marque nós onde as linhas estimadas divergem acentuadamente das linhas reais.
A - Disciplina de Captura
- Execute
ANALYZEnas tabelas afetadas antes de comparar planos. Linha de base de cardinalidade justa. - Use
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)para investigações. Tempos, I/O e contexto GUC. - Execute duas vezes em benchmarks; registre a segunda execução. Reduz ruído de cache frio.
- Anote a role,
search_pathe modo do pool (sessão vs transação). Planos diferem pela forma da sessão. - Armazene planos como JSON em CI para regressões. Artefatos amigáveis para diff.
B - Leitura da Árvore
- Encontre o nó com o maior
actual timeprimeiro. Otimize o gargalo real. - Compare as estimativas
rows=comactual rows=nos nós de condução. Sinaliza bugs de estatísticas ou correlação. - Verifique se há spill de sort/hash (
external merge Disk, lotes de hash > 1). Sinal de ajuste de memória. - Verifique se os nomes dos índices correspondem às migrações pretendidas. Índice errado significa correção errada.
- Leia
Heap Fetchesem tentativas de índice-only. O mapa de visibilidade pode precisar de vacuum.
C - Segurança de Produção
- Evite
EXPLAIN ANALYZEem SQL destrutivo semROLLBACK. ANALYZE executa a instrução. - Limite análises ad hoc com
statement_timeout. Proteja primárias compartilhadas. - Use réplicas de leitura ou snapshots mascarados para experimentos pesados. Isole o risco de OLTP.
- Redija literais contendo PII em logs compartilhados. Parametrize em aplicativos.
- Combine planos com totais de
pg_stat_statements. Confirme que a consulta importa em escala.
D - Validação de Mudanças
- Exija planos antes/depois em PRs de índice. Prove que o planejador usa o novo índice.
- Meça a amplificação de escrita de novos índices. Inserções pagam custo de manutenção.
- Reverifique planos após ETL em massa, não apenas após DDL. Estatísticas se desviam silenciosamente.
- Documente índices rejeitados com evidências de plano. Evite pedidos repetidos.
- Revisite planos após atualizações de versão principal. O planejador muda o comportamento.
FAQs
Opções mínimas de EXPLAIN para tickets?
ANALYZE, BUFFERS, SETTINGS em TEXT ou JSON.EXPLAIN sozinho é suficiente para produção?
Sim, para triagem de leitura quando o risco de ANALYZE é muito alto.Como compartilhar planos?
JSON em tickets; evite colar segredos em literais.auto_explain vs manual?
auto_explain captura lentidão em produção; manual reproduz com parâmetros.Quando escalar para pganalyze?
Muitos bancos de dados e rastreamento contínuo de regressão.Bitmap scan é bom ou ruim?
Neutro. Compare tempo total e buffers com alternativas.Forçar índice para teste?
enable_seqscan off apenas na sessão; nunca deixe em roles de produção.Nós paralelos?
Anote as contagens de Gather e workers; teste com configurações paralelas correspondentes à produção.Prepared statements?
Compare GENERIC_PLAN vs EXECUTE com valores de bind.Próxima página?
Estudos de caso de planos ruins para exemplos de desvio de estimativa.Relacionados
- Noções Básicas de EXPLAIN - Vocabulário de nós
- Estudos de Caso de Planos Ruins - Padrões de falha
- Melhores Práticas de Estatísticas - Higiene de estatísticas
- Padrões de Revisão de Consultas - Processo da equipe
Versões de Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.