Como você otimiza uma consulta de banco de dados lenta?

Question

Accepted Answer

**Comece com o plano de consulta e depois corrija o maior custo.** Use `EXPLAIN`/`EXPLAIN ANALYZE` para ver o que o banco de dados realmente faz, adicione os **índices** corretos, elimine consultas **N+1** e selecione apenas os dados de que você precisa.

## Leia o plano de consulta

`EXPLAIN ANALYZE` mostra o plano de execução e os tempos reais. Um **Seq Scan** em uma tabela grande é a bandeira vermelha clássica:

```sql
EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42;
-- Seq Scan on orders  (cost=0.00..18500 rows=120)
--   Filter: (customer_id = 42)
--   rows removed by filter: 999880   ← scanned the whole table!
```

## Adicione o índice correto

Um índice transforma uma varredura completa em uma busca rápida:

```sql
CREATE INDEX idx_orders_customer ON orders (customer_id);
-- Now: Index Scan using idx_orders_customer  (cost=0.42..8.5 rows=120)
--   1,000,000-row scan → ~120-row lookup
```

Os índices têm um **custo nas escritas**: cada INSERT/UPDATE também deve atualizar o índice, então indexe as colunas nas quais você filtra/une/ordena — não todas as colunas. Um índice **composto** `(customer_id, created_at)` atende `WHERE customer_id = ? ORDER BY created_at` em uma única estrutura.

## Corrija N+1 e over-fetching

O **problema N+1** — uma consulta para uma lista, depois uma por linha — é uma causa comum de lentidão. Substitua-o por eager loading, um `JOIN` ou `IN (...)` em lote:

```sql
-- N+1: 1 + 100 queries
SELECT * FROM orders;            -- then per order: SELECT * FROM users WHERE id = ?

-- Fixed: one JOIN, only needed columns
SELECT o.id, o.total, u.name
FROM orders o JOIN users u ON u.id = o.user_id;
```

Também **selecione apenas as colunas necessárias** (evite `SELECT *`) e **pagine** com `LIMIT`/keyset pagination para nunca carregar milhões de linhas.

## Por que isso importa

O banco de dados é o gargalo mais comum. Ler o plano diz *por que* uma consulta é lenta em vez de adivinhar; o índice correto, a remoção de N+1 e a redução do conjunto de resultados rotineiramente transformam consultas que duram segundos em milissegundos — sem escalar o hardware.