Uma consulta que demorou milissegundos no ano passado pode demorar minutos hoje, simplesmente porque a tabela cresceu. A otimização de consultas SQL tem menos a ver com truques inteligentes e mais com um processo repetível: descubra o que o banco de dados está fazendo, remova o trabalho desperdiçado e verifique se isso ajudou.

Testamos cada técnica abaixo em um milhão de linhas geradas no SQLite 3.50. Os tempos são os melhores de várias execuções de um laptop, usando um banco de dados na memória. Eles não corresponderão ao seu sistema, e PostgreSQL, MySQL e SQL Server têm, cada um, seus próprios otimizadores e formatos de plano. Concentre-se no tamanho de cada melhoria e nos princípios por trás dela.

Resumo dos resultados

A configuração do teste

CREATE TABLE customers (
  id INTEGER PRIMARY KEY, name TEXT, city TEXT
);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY, customer_id INT, status TEXT,
  created TEXT, total INT, note TEXT
);
-- 50,000 customers and 1,000,000 orders with random values

Um processo simples de otimização

1. Encontre as consultas importantes. Use registros de consultas lentas ou monitoramento. Uma consulta de 200 ms executada mil vezes por minuto pode ser mais importante do que um relatório mensal de 10 segundos.
2. Leia o plano. Veja o que o banco de dados realmente está fazendo.
3. Mude uma coisa. Adicione um índice ou reescreva parte da consulta.
4. Meça novamente com dados realistas. Um plano de 100 linhas de teste diz muito pouco sobre um milhão.
5. Acompanhe ao longo do tempo. Os planos podem mudar à medida que os dados crescem e as estatísticas mudam.

Leia um plano de execução

Um plano de execução é a estratégia passo a passo do banco de dados para executar uma consulta, incluindo quais índices ele usa e em que ordem ele une as tabelas. Prefixe uma consulta para vê-la:

Observe que EXPLAIN ANALYZE no PostgreSQL realmente executa a consulta, então tome cuidado ao usá-lo com UPDATE ou DELETE. Aqui está o que procurar primeiro:

Uma verificação completa não é automaticamente ruim. Se uma consulta precisar de uma tabela pequena, a digitalização pode ser a escolha mais rápida. No PostgreSQL EXPLAIN ANALYZE, compare também as linhas estimadas com as linhas reais. Uma grande diferença geralmente significa que as estatísticas da tabela estão desatualizadas.

Adicione o índice correto

Esta consulta encontra os pedidos de um cliente:

SELECT id, total FROM orders WHERE customer_id = 123;

Antes de adicionar um índice, o plano era uma verificação completa:

SCAN orders
-- 20 rows in 73 ms

Em seguida, adicionamos um índice na coluna do filtro:

CREATE INDEX idx_orders_customer ON orders(customer_id);

SEARCH orders USING INDEX idx_orders_customer (customer_id=?)
-- 20 rows in 0.01 ms

As mesmas 20 linhas voltaram milhares de vezes mais rápido, porque o banco de dados não lia mais um milhão de linhas para encontrá-las. Nenhuma outra técnica neste artigo nos proporcionou uma vitória maior. Bons primeiros candidatos são colunas usadas em WHERE, JOIN e ORDER BY, especialmente quando restringem os resultados a poucas linhas. Nosso guia sobre índices SQL explica como eles funcionam.

Não envolva colunas indexadas em funções

Aqui estão duas maneiras de encontrar pedidos de março, com índice em created:

-- Function on the column
SELECT id FROM orders WHERE substr(created, 1, 7) = '2026-03';
-- SCAN orders USING COVERING INDEX idx_orders_created
-- 84,961 rows in 96 ms

-- Plain range
SELECT id FROM orders
WHERE created >= '2026-03-01' AND created < '2026-04-01';
-- SEARCH orders USING COVERING INDEX idx_orders_created (created>? AND created<?)
-- 84,961 rows in 33 ms

Ambos retornam linhas idênticas, mas o primeiro demorou cerca de três vezes mais. O plano mostra o porquê: com uma função na coluna, o banco de dados não pode pular para uma posição no índice classificado, então precisa SCAN em cada entrada. A versão da gama pode SEARCH ir direto para o lugar certo. Uma condição que pode usar um índice dessa maneira é chamada sargable.

O mesmo problema aparece com estes padrões comuns:

Verificamos esse último também. Um curinga inicial produzido SCAN customers, como um índice classificado a partir da primeira letra, não pode ajudar na correspondência no final.

Índices compostos

Quando uma consulta é filtrada em duas colunas, um índice de coluna única faz apenas parte do trabalho:

SELECT id FROM orders
WHERE status = 'paid'
  AND created >= '2026-03-01' AND created < '2026-03-08';

-- Using only the created index: 6,198 rows in 19 ms

CREATE INDEX idx_status_created ON orders(status, created);

-- SEARCH orders USING COVERING INDEX idx_status_created
--   (status=? AND created>? AND created<?)
-- 6,198 rows in 2.2 ms

A ordem das colunas é muito importante. Um índice em (status, created) funciona como uma lista telefônica classificada por sobrenome e depois nome. Você pode procurar apenas um sobrenome, mas não apenas um nome. Somente nossa consulta em status poderia usar esse índice. Filtrar apenas created geralmente não poderia usá-lo de forma eficiente. Como regra geral, coloque as colunas testadas com igualdade primeiro e as colunas de intervalo depois delas.

Esse plano também diz abrangendo o índice, o que significa que o índice continha tudo o que a consulta precisava, portanto a tabela em si não precisava ser lida. Selecionar apenas as colunas necessárias torna isso mais provável, o que é outro motivo para evitar SELECT *.

Paginação mais rápida

Usar OFFSET para páginas profundas é um custo oculto, já que o banco de dados ainda precisa passar por todas as linhas ignoradas:

-- Page deep into the results
SELECT id FROM orders ORDER BY id LIMIT 20 OFFSET 500000;
-- 8.1 ms

-- Keyset pagination: continue from the last id seen
SELECT id FROM orders WHERE id > 500000 ORDER BY id LIMIT 20;
-- 0.01 ms

A paginação do conjunto de chaves permanece rápida, não importa o quão profundo você vá. Também evita a mudança de linhas entre páginas quando novos dados são adicionados. A desvantagem é que os usuários não podem ir direto para a página 5.000, o que raramente é uma necessidade real. Em tabelas com linhas largas ou com mais linhas para pular, a lacuna pode ser muito maior do que em nosso teste.

Escreva consultas mais enxutas

• Selecione apenas as colunas necessárias. SELECT * envia mais dados e pode impedir que um índice cubra a consulta.
• Filtrar antecipadamente. Use WHERE para remover linhas antes do agrupamento e HAVING apenas para condições em agregações. Consulte SQL GROUP BY e HAVING.
• Use LIMIT quando precisar apenas de algumas linhas.
• Prefira UNION ALL quando não precisar remover duplicatas. Nosso teste UNION vs UNION ALL mostra o que isso economiza.
• Evite DISTINCT desnecessário. Muitas vezes, é ocultar uma junção que produz duplicatas.
• Use EXISTS para verificações de existência. Ele pode parar na primeira correspondência, como explica nosso guia para subconsultas SQL.
• Observe as consultas N+1. Uma consulta por linha em um loop, geralmente causada pelo código do aplicativo, costuma ser o problema real. Uma única consulta de junção ou em lote pode substituir centenas de viagens de ida e volta.

Junta-se

Indexe as colunas nas quais você se une. Geramos um relatório de gastos totais para clientes em uma cidade, e o plano era exatamente o que você esperava:

SELECT c.name, SUM(o.total)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.city = 'Goa'
GROUP BY c.id;

-- SCAN c
-- SEARCH o USING COVERING INDEX idx_cover (customer_id=?)
-- 9,900 rows in 34 ms

Ele verifica os clientes e depois usa um índice para localizar os pedidos de cada um. Sem um índice em orders.customer_id, o banco de dados teria que trabalhar muito mais para cada cliente. Um índice na chave estrangeira é uma das adições mais comuns e valiosas que você pode fazer. Para atualizar sua compreensão dos conceitos básicos, consulte Explicação sobre junções SQL.

Quando os índices custam caro

Os índices não são gratuitos, portanto não adicione um para cada coluna:

• Gravações mais lentas. Cada inserção, atualização e exclusão também deve atualizar cada índice.
• Mais armazenamento e memória. Os índices podem crescer muito em tabelas grandes.
• Pouco benefício em colunas não seletivas. Um índice em uma coluna verdadeira ou falsa pode não ajudar se a maioria das linhas corresponder.
• Redundância. Um índice em (a) geralmente é desnecessário se você já tiver um em (a, b).

Verifique as estatísticas de uso periodicamente e remova índices que nada usa. E mantenha as estatísticas atualizadas com ANALYZE ou equivalente em seu banco de dados, porque o otimizador depende delas para escolher um bom plano. Às vezes, a parte lenta é a contenção, e não a consulta. Transações de longa duração que mantêm bloqueios podem fazer com que uma consulta rápida pareça lenta.

Erros comuns

• Otimizar sem medir. Muitas suposições confiantes revelam-se erradas.
• Testes com dados minúsculos. Os planos e os prazos mudam drasticamente à medida que as tabelas crescem.
• Confiar uma dica para outro banco de dados. Conselhos para um mecanismo podem não se aplicar a outro.
• Adicionando índices às cegas. Cada um deles retarda as gravações.
• Ignorando o efeito da primeira execução. Os caches tornam a segunda execução mais rápida, portanto, execute várias vezes.

Considerações finais

A maioria das consultas lentas tem causas comuns: um índice ausente, uma função em uma coluna ou muitos dados sendo buscados. Faça sua consulta real mais lenta desta semana, execute EXPLAIN nela e procure uma varredura completa em uma tabela grande. Corrija uma coisa, meça novamente e anote o que você mudou.

Perguntas frequentes

Continue aprendendo