EXPLAIN PLAN — Como Debugar Queries Lentas e Encontrar o Gargalo de Verdade Você tem uma query que demora 5 minutos pra rodar. Pode ser um problema de índice, de algoritmo, de full table scan. Ou pode ser tudo junto. A maioria dos desenvolvedores — mesmo sêniors — fica olhando pro código e chutando: "deve ser um índice que falta". Depois cria 5 índices aleatórios, a query fica 30% mais rápida, e ninguém aprende nada. Existe um jeito certo. Chama-se EXPLAIN PLAN. O Que É EXPLAIN PLAN EXPLAIN PLAN é um comando que mostra como o banco de dados planeja executar sua query antes de realmente executá-la. Não é mágica. É informação. E informação correta leva você direto ao problema. Quando você roda isso, o banco retorna não só o resultado, mas também: Quantas linhas ele vai examinar Quantas linhas ele vai filtrar Qual índice ele usou (ou não usou) Tempo estimado vs tempo real O Diagnóstico Típico: Sequential Scan vs Index Scan Se você roda EXPLAIN em uma query lenta, provavelmente vai ver algo assim: "Seq Scan" significa Sequential Scan — o banco leu TODAS as linhas da tabela do início ao fim, uma por uma. Se sua tabela tem 10 milhões de linhas, ele leu 10 milhões de linhas. Depois filtrou. Daí o "lento". Isso é tão comum que tem nome: é a causa raiz de ~70% das queries lentas que vejo. A Solução: Criar um Índice na Coluna Correta O comando abaixo cria um índice na coluna : Depois roda EXPLAIN novamente: Agora é "Index Scan" — o banco usou um índice (muito mais rápido). A diferença na prática: Antes: 5 minutos (Sequential Scan em 10M linhas) Depois: 50 milissegundos (Index Scan em ~10k linhas) Ganho: 6000x mais rápido. E você descobriu isso em 30 segundos com EXPLAIN, não em 30 minutos testando índices aleatórios. Lendo EXPLAIN: Os Campos Mais Importantes Quando você roda , aparece algo assim: Seq Scan: tipo de operação (pode ser Index Scan, Bitmap Scan, etc) cost=0.00..45000.00: custo estimado (números maiores = mais caro) rows=100000: quantas linhas vai retornar width=50: tamanho médio de cada linha em bytes O número mais importante é cost. Quanto maior, pior. Se você tem um join de 3 tabelas e vê , isso é um sinal de alerta. Algo está muito errado (provavelmente falta um índice). O Processo Correto (Sênior-Level) Aqui está como um sênior debug uma query lenta: Passo 1: Roda EXPLAIN ANALYZE na query problemática. Passo 2: Procura por: Seq Scans (🚩 vermelho) Bitmap Index Scans (⚠️ amarelo) Índices não sendo usados (🚩 vermelho) Estimativas muito diferentes do real (exemplo: estimado, mas real = problema de estatísticas) Passo 3: Cria índices nas colunas do WHERE e do JOIN. Passo 4: Roda EXPLAIN novamente. Se o cost caiu e agora usa Index Scan, ganhou. Passo 5: Se ainda está lento, procura por problemas mais complexos: Hash Join vs Nested Loop Join (às vezes um é 10x mais rápido que o outro) Falta de índice em foreign keys Selectividade ruim (índice não ajuda se o filtro retorna 50% das linhas) Casos Avançados: Quando EXPLAIN Mostra Limites Às vezes, EXPLAIN mostra um cost enorme, mas a query realmente precisa processar muitos dados. Exemplo: você quer contar todos os usuários ativos. Não tem índice que resolva isso — o banco TEM que ler todas as linhas. Nesse caso, EXPLAIN não é o problema. O problema é você pedindo algo que custa caro naturalmente. Solução: usar materialização (tabelas pré-computadas) ou mudança de arquitetura (event streaming, incrementalização). Mas isso é tópico avançado. Na maioria dos casos (~90%), EXPLAIN mostra um problema óbvio: falta de índice ou join com ordem ruim. Checklist: Quando Você Sabe Que Debugou Certo ✅ Rodei EXPLAIN ANALYZE ✅ Identifiquei Seq Scans problemáticos ✅ Criei índices nas colunas certas ✅ Rodei EXPLAIN novamente e vi Index Scan ✅ Cost caiu significativamente (10x+ de melhoria) ✅ Tested no ambiente parecido com produção (dados reais, volume real) Se todos os ✅ estão marcados, você debugou corretamente. A Regra Ouro Nunca, nunca, NUNCA reclame que uma query é lenta sem rodar EXPLAIN primeiro. Se você for em uma reunião e disser "a query está lenta e precisa de optimização", o gestor vai perguntar "você rodou EXPLAIN?". Se a resposta for não, você perdeu credibilidade. Se a resposta for sim, você já sabe EXATAMENTE qual é o problema e como resolver. Isso é profissionalismo. Quer dominar SQL de verdade e entender performance? Na Elite Data Academy, a trilha de SQL Avançado começa aqui — com o ferramental que você realmente usa todo dia em produção. Aprenda com quem está no mercado hoje em elite-data-academy.paanalytics.net