EXPLAIN ANALYZE no PostgreSQL: encontrar consultas lentas passo a passo
Publicado em 2026-10-26 por frfrand
Plano de execução e índices do PostgreSQL para otimizar APIs
Uma lista de reservas demora três segundos e alguém propõe duplicar o VPS. Antes de pagar mais CPU, veja como o PostgreSQL executa essa consulta. EXPLAIN ANALYZE mostra o plano real, tempos e linhas processadas.
A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo à produção.
O que o EXPLAIN ANALYZE faz no PostgreSQL
EXPLAIN estima um plano sem executar a consulta; com ANALYZE ele a executa e registra métricas reais. Em SELECT costuma ser apropriado para analisar, mas com operações que modificam dados pode produzir alterações: nunca o execute alegremente em consultas de gravação em produção.
Não basta repetir uma receita se você não entender quem lê os dados, de qual processo e com quais permissões. Em um aplicativo com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave do que uma API lenta.
Um exemplo concreto
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, fecha, estado
FROM reservas
WHERE cliente_id = 42
ORDER BY fecha DESC
LIMIT 20;
-- Comparar estimaciones y ejecución real
EXPLAIN SELECT * FROM reservas WHERE cliente_id = 42;Os nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de ensaio e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de exemplo sobre dados de clientes sem revisar o que elas modificam.
Passo a passo
- Reproduza a lentidão com dados similares aos de produção e uma SELECT representativa.
- Observe a duração total, as linhas estimadas e as linhas reais.
- Identifique sequenciais grandes, ordenações custosas e acessos repetidos.
- Avalie um índice compatível com filtros e ordem, mas comprove o efeito sobre gravações.
- Meça novamente a consulta e o p95 da API, não apenas o custo estimado do plano.
No final, não fique com «o SQL não deu erro». Comprove o efeito real desde a API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.
Exemplo de projeto de trabalho
Uma plataforma de reservas busca os últimos pedidos de cada cliente. Um índice composto sobre (cliente_id, data DESC) pode melhorar a consulta se coincidir com os padrões de acesso e distribuição de dados.
Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não serve se permitir criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.
O erro típico
Criar índices para cada coluna não é gratuito; ocupam espaço e penalizam algumas gravações. ANALYZE executa consultas: não use exemplos de DELETE/UPDATE em produção sem transação e controles explícitos.
Também vale a pena ter um plano de recuperação. Antes de alterar esquema, usuários ou políticas, faça uma cópia verificável ou migração reversível e verifique se o aplicativo pode continuar funcionando durante a mudança.
Como resolveria com ArduMaker?
No PostgreSQL hospedado no ArduMaker, você pode revisar consultas lentas e recursos do VPS. Se o gargalo estiver em um plano SQL ineficiente, aumentar a CPU não necessariamente ajuda.
O ArduMaker permite implantar serviços a partir do Git e trabalhar com bancos de dados e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem estar corretamente projetadas no código e no banco de dados.
Três verificações antes de publicar
Integridade: se uma solicitação for repetida ou falhar no meio do caminho, os dados terminam em um estado válido?
Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco de dados com permissões mínimas?
Recuperação: você sabe restaurar os dados e reverter a versão de código compatível se uma atualização der errado?
Se você puder responder a essas três perguntas com provas, seu backend está bastante mais preparado do que quando você apenas verificou se o endpoint retornava 200.
Recursos para aprofundar
Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.