Banco de dados lento? Como auditar queries no PostgreSQL

Por que o banco de dados começa a ficar lento de repente?

Quando uma aplicação web cresce, é comum que rotinas diárias e relatórios comecem a demorar segundos preciosos para responder. Na maioria das vezes, o culpado não é a infraestrutura fraca, mas sim uma consulta SQL mal estruturada que obriga o motor do banco a ler tabelas inteiras linha por linha. No PostgreSQL, a ferramenta mais poderosa para descobrir o motivo exato de uma lentidão é o plano de execução, gerado pelo comando EXPLAIN. Assim como em sistemas comparados ao lidar com gargalos de consultas lentas no MySQL, entender como o banco enxerga seu código é o primeiro passo para resolver o problema.

Na prática, o plano de execução funciona como um mapa rodoviário que o banco de dados desenha antes de entregar a resposta solicitada. Quando você digita uma query, o planejador interno do PostgreSQL analisa dezenas de caminhos possíveis, calculando o custo estimado de tempo e processamento para cada um deles. Ele decide se vale a pena usar um índice criado na coluna ou abrir cada arquivo físico do disco rígido para procurar a informação. Saber interpretar esse mapa elimina a adivinhação e permite correções cirúrgicas no código e na arquitetura do sistema.

Como extrair o primeiro plano de execução com EXPLAIN

Para começar a auditar, você não precisa alterar nenhuma linha de código em produção, bastando abrir sua ferramenta de gerenciamento e adicionar a palavra EXPLAIN antes da sua consulta habitual. No entanto, existe um detalhe fundamental que muitos desenvolvedores esquecem: por padrão, o comando apenas simula e estima o custo sem de fato executar a operação. Se você quiser ver o tempo real que o banco gastou e quantas linhas ele realmente leu, deve usar o parâmetro ANALYZE junto, obtendo dados reais de desempenho e consumo de recursos.

Veja abaixo um exemplo prático de como aplicar o comando em uma consulta típica que busca pedidos de clientes:

EXPLAIN ANALYZE SELECT * FROM pedidos WHERE status = 'pendente' AND valor > 500.00;

Quando você roda esse comando, o PostgreSQL devolve um texto estruturado em árvore. Cada linha desse relatório mostra um nó de operação, indicando se o banco fez uma varredura sequencial ou se utilizou algum índice existente. A leitura desse resultado é feita de dentro para fora, ou seja, as operações que aparecem mais aninhadas no texto são executadas primeiro, alimentando as etapas superiores até o resultado final chegar à sua tela.

Entendendo a diferença entre Seq Scan e Index Scan

O maior vilão da performance na maioria dos bancos relacionais é o temido Seq Scan, abreviação para Sequential Scan ou varredura sequencial. Na prática, isso significa que o PostgreSQL teve de ler fisicamente cada bloco de dados da tabela inteira, do primeiro ao último registro, apenas para encontrar os poucos registros que atendiam ao seu filtro. Se a sua tabela tem dez mil linhas, o impacto é pequeno, mas quando ela alcança dezenas de milhões de registros, essa operação consome toda a memória RAM disponível e dispara o uso de disco.

Para evitar esse comportamento indesejado, a engenharia de dados utiliza os índices, que funcionam de forma semelhante ao índice remissivo no final de um livro didático. Quando o planejador escolhe um Index Scan, ele consulta primeiro essa estrutura auxiliar ordenada para descobrir o endereço exato do registro no disco, saltando direto ao ponto desejado. Contudo, criar índices de forma desordenada também traz efeitos colaterais, pois cada inserção e atualização de dados precisará modificar essas estruturas extras, exigindo equilíbrio técnico na modelagem das tabelas.

Como interpretar os custos, tempos e estimativas

Dentro do relatório gerado pelo EXPLAIN, você encontrará termos como cost (custo) e actual time (tempo real). O custo é uma unidade abstrata definida pelo próprio PostgreSQL para medir o esforço computacional, onde o acesso sequencial a uma página de disco equivale a um custo base. Esses números ajudam o planejador a escolher o caminho mais barato, mas podem falhar se as estatísticas internas do banco estiverem desatualizadas, o que frequentemente ocorre após grandes volumes de exclusão ou inserção de dados.

Outro ponto crítico a observar no relatório é a divergência entre estimated rows (linhas estimadas) e actual rows (linhas reais). Se o planejador calcular que uma condição trará apenas cinco linhas, mas na prática ela retornar quinhentos mil registros, ele poderá escolher um algoritmo de junção inadequado que vai travar o servidor. Para manter essas previsões sempre precisas, o banco de dados executa periodicamente uma rotina de manutenção chamada VACUUM e ANALYZE, que atualiza o catálogo de estatísticas sobre a distribuição dos dados nas colunas.

Identificando gargalos em junções de tabelas e ordenações

Consultas complexas costumam envolver junções (joins) entre várias tabelas e ordenações pesadas com a cláusula ORDER BY. Quando o EXPLAIN mostra operações chamadas Hash Join ou Nested Loop, ele está revelando como o PostgreSQL combinou os dados. O Nested Loop funciona como dois loops encadeados em programação, sendo excelente para conjuntos pequenos, mas desastroso para bases grandes. Já o Hash Join constrói uma tabela temporária em memória para cruzar os dados rapidamente, embora possa estourar a memória disponível se o resultado for grande demais.

Quando a memória alocada para essas operações é insuficiente, o banco de dados recorre ao disco para fazer parte do processamento, fenômeno conhecido na engenharia como spill to disk. Essa troca constante de dados entre a memória RAM e o armazenamento físico derruba a performance de forma drástica, lembrando os travamentos severos que ocorrem quando um sistema operacional esgota a memória física e aciona o arquivo de paginação, cenário similar ao investigado ao auditar limites de memória e OOM Killer em containers. Ajustar parâmetros como work_mem no arquivo de configuração do PostgreSQL evita esse comportamento indesejado. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Como testar o circuito integrado de rede com multímetro.

Conclusão

Auditar consultas lentas utilizando o comando EXPLAIN transforma a forma como você encreve e gerencia o código no dia a dia, saindo do achismo para decisões baseadas em dados concretos de desempenho. Ao decifrar os planos de execução, você aprende a identificar varreduras desnecessárias, criar índices no momento certo e evitar que operações pesadas estrangulem os recursos do servidor.

Dominar essa ferramenta é um divisor de águas na carreira de qualquer desenvolvedor ou administrador de sistemas que trabalha com bancos relacionais. O hábito de analisar o plano de consultas antes de colocar qualquer código em produção garante sistemas escaláveis, resilientes e capazes de entregar uma experiência rápida e consistente para os usuários finais.