Como você usa EXPLAIN e EXPLAIN ANALYZE?

Question

Accepted Answer

**`EXPLAIN`** mostra o **plano de execução de consulta** do PostgreSQL — como executará uma consulta (quais scans, joins, índices). **`EXPLAIN ANALYZE`** realmente executa a consulta e mostra tempos reais e contagens de linhas. Essas são as ferramentas principais para diagnosticar consultas lentas.

## EXPLAIN — o plano (sem executar)

```sql
EXPLAIN SELECT * FROM orders WHERE customer_id = 5;
-- shows the PLAN: scan type, estimated cost, estimated rows — but doesn't run it
```

## EXPLAIN ANALYZE — o plano com dados de execução REAIS

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- ACTUALLY runs it → shows REAL time, ACTUAL rows, and where time was spent
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;   -- also shows buffer/cache usage
```

`EXPLAIN ANALYZE` é mais útil porque mostra desempenho *real* (tempo real, contagens de linhas reais) — revelando onde a consulta realmente gasta tempo, não apenas estimativas.

## Lendo o plano: as coisas principais a procurar

```text
SCAN TYPES (most important):
  Seq Scan      → FULL TABLE SCAN (reads every row) — slow on big tables, often the problem
  Index Scan    → uses an index to find rows — fast
  Index Only Scan → reads only the index (doesn't touch the table) — fastest
  Bitmap Scan   → for combining indexes / many matches

WATCH FOR:
  ✗ Seq Scan on a large table being filtered → likely a MISSING INDEX
  ✗ Estimated rows VERY different from actual rows → outdated statistics (run ANALYZE)
  ✗ Expensive joins, sorts spilling to disk ("external merge")
  ✗ The node with the highest actual time = the bottleneck
```

## Um exemplo diagnóstico

```sql
EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Seq Scan on orders ... actual time=120ms" → a full scan, slow

CREATE INDEX idx_orders_customer ON orders(customer_id);

EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 5;
-- "Index Scan using idx_orders_customer ... actual time=0.05ms" → fixed!
```

## Por que isso importa

`EXPLAIN` e `EXPLAIN ANALYZE` são ferramentas essenciais e primárias para **diagnosticar e otimizar consultas lentas** no PostgreSQL — o desempenho de consultas é crítico para aplicações, e essas ferramentas são como você entende *por que* uma consulta é lenta e verifica correções, então dominá-las é conhecimento importante de nível sênior para trabalho de desempenho de banco de dados.

O valor fundamental é **visibilidade no plano de execução**: ao invés de adivinhar por que uma consulta é lenta, `EXPLAIN ANALYZE` (que executa a consulta e mostra tempo real e contagens de linhas) revela exatamente como Postgres a executa e onde o tempo é gasto.

As coisas mais importantes a reconhecer são os **tipos de scan** — especialmente identificar um **`Seq Scan` (full table scan)** em uma tabela grande filtrada, que geralmente indica um **índice ausente** (o problema de desempenho de consulta mais comum e impactante), versus um rápido **`Index Scan`**.

Entender como ler o plano (tipos de scan, comparando linhas estimadas vs reais para detectar estatísticas desatualizadas, identificando o nó mais custoso como gargalo, observando sorts que derramam em disco) é a habilidade-chave para otimização de consultas.

O fluxo de trabalho diagnóstico — executar `EXPLAIN ANALYZE`, identificar o gargalo (geralmente um Seq Scan), aplicar a correção (geralmente adicionando um índice) e re-executar para verificar — é a abordagem padrão, orientada por medição, para otimização de consultas.

Com consultas lentas sendo uma das principais causas de desempenho ruim de banco de dados, e com `EXPLAIN`/`EXPLAIN ANALYZE` sendo *as* ferramentas para diagnosticá-las (revelando índices ausentes, planos ruins e gargalos) e verificar otimizações, dominá-las é conhecimento importante e de alto valor para desempenho PostgreSQL — é como você encontra e corrige sistematicamente consultas lentas ao invés de adivinhar, uma habilidade crítica para bancos de dados eficientes e um tópico comum para trabalho de otimização de banco de dados.