# Otimizar queries SQL: guia prático para melhor performance > O guia prático de otimização de queries SQL apresenta técnicas como uso de índices, reescrita de subconsultas e análise de planos de execução para melhorar a performance de consultas em bancos de dados. As estratégias focam em passos seguros e eficazes, evitando truques arriscados que possam comprometer a integridade dos dados. *TNT Web · Apps e Software · 29 de julho de 2026 · Dani Travassos* Quer melhorar a performance das suas consultas? Este guia mostra como otimizar queries SQL com passos práticos, desde o uso de índices até a reescrita de subconsultas. Sem truques arriscados. Otimizar queries SQL é uma tarefa que mistura técnica e cautela. Uma consulta mal escrita pode travar um sistema inteiro, mas uma otimização agressiva pode piorar o que já estava funcionando. O objetivo deste guia é mostrar um caminho seguro: você vai aprender a analisar, ajustar e testar cada mudança sem comprometer a integridade dos dados. Antes de começar, tenha acesso ao banco de dados com permissão para executar EXPLAIN ou comando equivalente, e um ambiente de testes com dados representativos - nunca mexa em produção sem validação. **Passo 1: Identifique o gargalo com o plano de execução** O primeiro passo de qualquer otimização é entender o que o banco de dados está fazendo com sua query. Use o comando EXPLAIN (ou EXPLAIN ANALYZE no PostgreSQL, EXPLAIN PLAN no Oracle) para ver o plano de execução. Ele mostra quais índices foram usados, quantas linhas foram varridas e o custo relativo de cada operação. Um erro comum aqui é pular essa análise e sair alterando índices ou reescrevendo a query no escuro. Sem o plano, você está chutando. Exemplo: uma consulta que faz um FULL TABLE SCAN em uma tabela de milhões de linhas é um sinal claro de que um índice está faltando. **Passo 2: Crie índices nas colunas certas** Índices aceleram buscas, mas cada índice extra torna as operações de INSERT, UPDATE e DELETE mais lentas. O equilíbrio é delicado. Crie índices nas colunas que aparecem nas cláusulas WHERE, JOIN e ORDER BY. Para colunas com baixa cardinalidade (poucos valores distintos, como 'sim'/'não'), um índice pode não ajudar muito. Um erro comum é criar um índice composto com a ordem errada: a coluna mais seletiva deve vir primeiro. Por exemplo, em uma tabela de pedidos, um índice em (data_pedido, status) funciona melhor se você filtra por data primeiro. Sempre teste a query com e sem o índice antes de aplicar. *_Passo 3: Evite SELECT_ e busque só o necessário** SELECT * é prático, mas carrega todas as colunas da tabela, inclusive aquelas que você não usa. Isso aumenta a transferência de dados entre o banco e a aplicação, além de impedir o uso de índices covering (que cobrem toda a consulta). Reescreva listando apenas as colunas que realmente precisa. Exemplo: em vez de SELECT * FROM clientes WHERE cidade = 'São Paulo', use SELECT id, nome, telefone FROM clientes WHERE cidade = 'São Paulo'. A diferença de performance fica mais evidente em tabelas com muitas colunas ou com campos grandes (TEXT, BLOB). **Passo 4: Prefira EXISTS a IN para subconsultas** Subconsultas com IN podem ser mais lentas que EXISTS, especialmente quando a subconsulta retorna muitas linhas. O EXISTS interrompe a varredura assim que encontra o primeiro registro correspondente, enquanto IN precisa processar todos os resultados da subconsulta. Exemplo: SELECT * FROM pedidos WHERE EXISTS (SELECT 1 FROM itens WHERE itens.pedido_id = pedidos.id) costuma ser mais rápido que SELECT * FROM pedidos WHERE id IN (SELECT pedido_id FROM itens). Mas isso varia conforme o SGBD e os índices disponíveis - teste ambos com EXPLAIN. **Passo 5: Cuidado com funções em cláusulas WHERE** Usar funções em colunas dentro do WHERE pode inutilizar um índice. Por exemplo, WHERE YEAR(data_criacao) = 2024 força uma varredura completa, pois o banco precisa aplicar a função em cada linha. A solução é reescrever a condição para usar um intervalo: WHERE data_criacao >= '2024-01-01' AND data_criacao - [ ] Analisei o plano de execução da query original. - [ ] Criei índices nas colunas de WHERE, JOIN e ORDER BY, testando o impacto. - [ ] Substituí SELECT * por colunas específicas. - [ ] Troquei IN por EXISTS onde aplicável. - [ ] Reescrevi funções em WHERE para usar intervalos. - [ ] Apliquei filtros o mais cedo possível na consulta. - [ ] Removi JOINs desnecessários e ajustei o tipo de JOIN. ## Perguntas frequentes sobre otimizar queries SQL ### O que é um plano de execução e como ele ajuda? O plano de execução é um mapa que mostra como o banco de dados vai executar sua consulta: quais índices usa, quantas linhas varre e o custo de cada operação. Ele ajuda a identificar gargalos como varreduras completas de tabela ou junções ineficientes. Use EXPLAIN (ou EXPLAIN ANALYZE) antes e depois de cada alteração. ### Como saber se um índice está sendo usado? Verifique no plano de execução se aparece "Index Scan" ou "Index Seek" em vez de "Seq Scan" ou "Full Table Scan". Se o índice não aparece, pode ser que a condição WHERE não seja seletiva o suficiente ou que uma função na coluna esteja bloqueando o uso. Nesse caso, reveja a query ou o índice. ### Qual a diferença entre IN e EXISTS na prática? IN processa toda a subconsulta e depois compara os valores. EXISTS interrompe a subconsulta assim que encontra a primeira correspondência. Para subconsultas que retornam muitas linhas, EXISTS tende a ser mais rápido. Mas com índices adequados e poucos registros, a diferença pode ser irrelevante. Sempre teste. ### Posso otimizar queries em produção? Evite fazer alterações diretamente em produção. Use um ambiente de testes com dados e volume similares. Mudanças como criação de índices ou reescrita de queries podem ter efeitos colaterais em outras consultas. Se for inevitável, faça fora do horário de pico e monitore o desempenho. ### O que é um índice covering? É um índice que contém todas as colunas necessárias para responder a uma consulta sem precisar acessar a tabela principal. Por exemplo, se a query busca apenas as colunas id e nome, um índice que inclua ambas permite que o banco leia só o índice, acelerando a consulta. Útil para consultas frequentes com poucas colunas. ### Como evitar que a otimização piore a performance? Sempre teste cada mudança isoladamente, comparando o plano de execução e o tempo de resposta antes e depois. Não aplique várias alterações de uma vez. Monitore também o impacto em operações de escrita (INSERT, UPDATE, DELETE), pois índices extras as tornam mais lentas. Documente cada ajuste para poder reverter se necessário. --- Fonte (canonical): https://tntweb.com.br/apps-e-software/otimizar-queries-sql-guia-pratico-para-melhor-performance/