Consultas SQL na Prática: SELECT, JOIN e Mais em 2026

Consultas SQL: resposta rápida

SELECT
    c.nome,
    COUNT(p.id) AS quantidade_pedidos,
    SUM(p.total) AS valor_total
FROM clientes AS c
INNER JOIN pedidos AS p ON p.cliente_id = c.id
WHERE p.status = 'pago'
  AND p.criado_em >= DATE '2026-01-01'
GROUP BY c.id, c.nome
HAVING SUM(p.total) >= 1000
ORDER BY valor_total DESC
LIMIT 10;

A consulta encontra os dez clientes com maior valor em pedidos pagos desde o início de 2026, considerando apenas quem somou pelo menos mil unidades monetárias. Cada cláusula tem uma responsabilidade.

Quando a pergunta está escrita em português claro antes do código, fica mais fácil conferir se o resultado corresponde à intenção.

Cláusula	Função	Exemplo
SELECT	Define as colunas do resultado	nome e valor total
FROM	Indica a fonte principal	clientes
JOIN	Relaciona outras fontes	pedidos do cliente
WHERE	Filtra linhas antes da agregação	somente pedidos pagos
GROUP BY	Forma grupos	um grupo por cliente
HAVING	Filtra grupos calculados	total mínimo
ORDER BY	Ordena a saída	maior total primeiro
LIMIT	Restringe a quantidade	dez linhas

O esquema usado nos exemplos

Os exemplos consideram uma loja com quatro tabelas. clientes guarda id, nome, cidade e ativo. pedidos possui id, cliente_id, status, total e criado_em. itens_pedido relaciona pedido, produto, quantidade e preço unitário. produtos possui nome, categoria e preço atual.

A chave primária identifica cada linha. A chave estrangeira pedidos.cliente_id aponta para clientes.id. Essa relação permite combinar dados sem repetir nome e cidade em cada pedido. O guia sobre bancos de dados relacionais aprofunda normalização, chaves e SGBDs.

Os comandos seguem SQL amplamente reconhecido e usam PostgreSQL nos pontos em que o dialeto importa. MySQL, SQL Server, Oracle e SQLite possuem diferenças em datas, funções, paginação e recursos avançados. Consulte sempre a documentação da versão usada no projeto.

Como montar uma consulta SELECT

Comece pela menor consulta que prova a origem dos dados. Acrescente um filtro por vez, execute, verifique a quantidade de linhas e só então inclua agregações ou tabelas adicionais.

Essa construção incremental facilita descobrir onde um resultado deixou de corresponder à expectativa.

SELECT id, nome, cidade
FROM clientes;

A referência oficial do PostgreSQL para SELECT mostra que a instrução também pode conter WITH, operações de conjuntos, bloqueios e outras opções.

Você não precisa decorar toda a gramática: domine o fluxo comum e consulte a referência para casos específicos.

Ordem lógica de execução

Embora escrevamos SELECT primeiro, a interpretação lógica começa aproximadamente em FROM e JOIN, passa por WHERE, GROUP BY, HAVING, SELECT, DISTINCT, ORDER BY e limitação.

O otimizador pode executar fisicamente de outra forma, desde que preserve o resultado.

Essa ordem explica por que um alias criado no SELECT normalmente não está disponível no WHERE da mesma consulta: o filtro lógico ocorre antes. Use a expressão original, uma subconsulta ou uma CTE quando precisar filtrar um valor calculado.

Selecionar colunas e criar aliases

SELECT
    p.id AS pedido_id,
    p.total AS valor_pedido,
    p.criado_em AS data_pedido
FROM pedidos AS p;

Aliases curtos ajudam em consultas com várias tabelas, mas devem continuar reconhecíveis. Selecione as colunas necessárias em aplicações e integrações. Isso reduz tráfego, evita expor dados inesperados e protege o consumidor quando novas colunas forem acrescentadas à tabela.

Filtrar linhas com WHERE

WHERE mantém apenas linhas cuja condição resulta em verdadeiro. Compare valores do tipo correto: texto com texto, datas com datas e números com números.

Conversões implícitas podem produzir erro, comportamento diferente entre bancos ou impedir o uso de índices.

SELECT id, cliente_id, total, criado_em
FROM pedidos
WHERE status = 'pago'
  AND total >= 200;

Operadores de comparação e lógica

Use =, <>, >, >=, < e <= para comparar. AND exige que as condições sejam verdadeiras; OR aceita uma delas; NOT inverte. Parênteses tornam a precedência explícita.

SELECT id, nome, cidade
FROM clientes
WHERE ativo = TRUE
  AND (cidade = 'São Paulo' OR cidade = 'Campinas');

Sem parênteses, a combinação de AND e OR pode selecionar linhas diferentes do esperado.

Em regras importantes, escreva testes com casos que devem entrar e casos que devem ficar de fora.

IN, BETWEEN e LIKE

SELECT id, status, total
FROM pedidos
WHERE status IN ('pago', 'enviado')
  AND total BETWEEN 100 AND 500;

BETWEEN inclui os extremos. Em timestamps, é mais seguro usar intervalo semiaberto — maior ou igual ao início e menor que o início do dia seguinte — para não depender de frações de segundo.

LIKE procura padrões de texto; % representa qualquer sequência e _, um caractere.

SELECT id, nome
FROM produtos
WHERE nome LIKE 'Caderno%';

Uma busca iniciada por curinga, como LIKE '%caderno%', frequentemente não aproveita um índice B-tree comum. Para pesquisa textual ampla, avalie recursos do SGBD ou um mecanismo apropriado.

Como tratar NULL corretamente

NULL representa valor ausente ou desconhecido, não texto vazio nem zero. Comparações com = NULL não retornam verdadeiro. Use IS NULL e IS NOT NULL.

A lógica possui um terceiro estado, desconhecido, que afeta filtros e negações.

SELECT id, nome
FROM clientes
WHERE cidade IS NULL;

COALESCE devolve o primeiro valor não nulo, mas não deve esconder um problema de qualidade.

Diferencie “sem cidade informada” de uma cidade real e evite substituir automaticamente por algo que altere o significado.

Ordenar e limitar resultados

SELECT id, cliente_id, total, criado_em
FROM pedidos
ORDER BY criado_em DESC, id DESC
LIMIT 20;

Sem ORDER BY, a ordem não é garantida, mesmo que pareça estável em testes.

Acrescente um critério de desempate único, como id, para paginação e relatórios reproduzíveis. ASC é crescente; DESC, decrescente.

Quando usar DISTINCT

SELECT DISTINCT cidade
FROM clientes
WHERE cidade IS NOT NULL
ORDER BY cidade;

DISTINCT remove linhas duplicadas do resultado inteiro. É adequado quando a pergunta pede valores únicos. Usá-lo para “consertar” duplicação causada por JOIN pode esconder erro e acrescentar custo. Investigue a cardinalidade primeiro.

Funções e expressões úteis

Consultas podem transformar a apresentação sem alterar os dados armazenados.

Funções de texto, data e número variam entre SGBDs. Operações como LOWER, UPPER, ROUND, COALESCE e concatenação são comuns, mas detalhes de tipos e formatação precisam ser confirmados no banco.

SELECT id, UPPER(nome) AS nome_exibicao,
       COALESCE(cidade, 'Não informada') AS cidade_exibicao
FROM clientes;

Criar categorias com CASE

SELECT id, total,
    CASE
        WHEN total >= 1000 THEN 'alto'
        WHEN total >= 300 THEN 'medio'
        ELSE 'baixo'
    END AS faixa_valor
FROM pedidos;

CASE avalia condições em ordem e para na primeira correspondência. Documente faixas, especialmente limites, e não duplique uma regra crítica em dezenas de relatórios.

Uma view ou camada semântica pode centralizar a definição.

Agregações com GROUP BY e HAVING

COUNT, SUM, AVG, MIN e MAX resumem várias linhas. Funções agregadas calculam um resultado a partir de um conjunto de entradas; com GROUP BY, esse conjunto é dividido por chaves.

SELECT status, COUNT(*) AS quantidade,
       SUM(total) AS valor_total, AVG(total) AS ticket_medio
FROM pedidos
GROUP BY status
ORDER BY valor_total DESC;

COUNT(*) conta linhas; COUNT(coluna) ignora valores nulos. A média das médias raramente equivale à média geral quando os grupos têm tamanhos diferentes.

Mantenha soma e quantidade ou calcule sobre as linhas originais.

Diferença entre WHERE e HAVING

SELECT cliente_id, SUM(total) AS valor_total
FROM pedidos
WHERE status = 'pago'
GROUP BY cliente_id
HAVING SUM(total) >= 1000;

WHERE remove pedidos antes de agrupar. HAVING remove grupos depois da soma.

Coloque condições de linha no WHERE por clareza e para reduzir o volume; reserve HAVING para condições que dependem da agregação.

Como combinar tabelas com JOIN

Um JOIN cria combinações de linhas segundo uma condição. Antes de escrever, pergunte qual é a cardinalidade: um cliente pode ter muitos pedidos; um pedido pode ter muitos itens.

A documentação oficial de JOIN do PostgreSQL apresenta a combinação entre tabelas e o comportamento das junções externas.

INNER JOIN

SELECT p.id AS pedido_id, c.nome AS cliente, p.total
FROM pedidos AS p
INNER JOIN clientes AS c ON c.id = p.cliente_id
WHERE p.status = 'pago';

INNER JOIN retorna apenas pares com correspondência. Pedidos com chave inválida e clientes sem pedidos não aparecem.

Use as chaves na condição ON; a sintaxe explícita torna a intenção clara e reduz o risco de produto cartesiano acidental.

LEFT JOIN

SELECT c.id, c.nome, COUNT(p.id) AS quantidade_pedidos
FROM clientes AS c
LEFT JOIN pedidos AS p
    ON p.cliente_id = c.id AND p.status = 'pago'
GROUP BY c.id, c.nome;

Todos os clientes permanecem; quando não há pedido pago, colunas de p ficam nulas e COUNT(p.id) resulta em zero.

Se o filtro de status fosse movido para o WHERE, linhas sem correspondência seriam eliminadas e o efeito se aproximaria de INNER JOIN.

RIGHT JOIN, FULL JOIN e CROSS JOIN

RIGHT JOIN preserva todas as linhas da tabela à direita e geralmente pode ser reescrito como LEFT JOIN invertendo a ordem.

FULL JOIN preserva os dois lados, útil em reconciliação. CROSS JOIN cria todas as combinações possíveis e cresce multiplicando as quantidades; use apenas quando intencional.

Por que JOIN pode duplicar linhas

Se um pedido possui três itens, combinar pedidos e itens produz três linhas para aquele pedido.

Somar pedidos.total depois desse JOIN triplica o valor. Agregue itens antes, calcule a partir de quantidade e preço ou mantenha a granularidade explícita.

SELECT ip.pedido_id,
       SUM(ip.quantidade * ip.preco_unitario) AS total_calculado
FROM itens_pedido AS ip
GROUP BY ip.pedido_id;

Subconsultas: quando fazem sentido

Uma subconsulta produz um valor, uma linha ou uma tabela usada pela consulta externa.

É útil para isolar um cálculo, comparar com uma referência ou expressar existência. O otimizador pode transformar várias subconsultas em planos eficientes; escolha primeiro pela correção e legibilidade, depois meça.

SELECT id, cliente_id, total
FROM pedidos
WHERE total > (SELECT AVG(total) FROM pedidos);

EXISTS e NOT EXISTS

SELECT c.id, c.nome
FROM clientes AS c
WHERE NOT EXISTS (
    SELECT 1 FROM pedidos AS p
    WHERE p.cliente_id = c.id
);

EXISTS verifica se ao menos uma linha existe; as colunas selecionadas internamente não importam. Para procurar ausência, NOT EXISTS costuma ser mais seguro que NOT IN quando a subconsulta pode produzir NULL.

CTEs com WITH para organizar consultas

WITH totais_por_cliente AS (
    SELECT cliente_id, SUM(total) AS valor_total
    FROM pedidos WHERE status = 'pago'
    GROUP BY cliente_id
)
SELECT c.nome, t.valor_total
FROM totais_por_cliente AS t
INNER JOIN clientes AS c ON c.id = t.cliente_id
WHERE t.valor_total >= 1000
ORDER BY t.valor_total DESC;

Uma CTE dá nome a uma etapa e facilita testar partes da consulta. Ela não é automaticamente mais rápida.

Dependendo do banco, versão e opções, pode ser incorporada ao plano ou materializada. Use para comunicar intenção e confira o plano quando desempenho importar.

Funções de janela sem perder detalhes

Agregação comum reduz várias linhas a uma por grupo. Funções de janela calculam sobre linhas relacionadas e preservam cada linha.

A introdução oficial a funções de janela explica OVER, PARTITION BY, ordenação e frames.

ROW_NUMBER e ranking por grupo

SELECT cliente_id, id AS pedido_id, total,
       ROW_NUMBER() OVER (
           PARTITION BY cliente_id
           ORDER BY criado_em DESC, id DESC
       ) AS posicao
FROM pedidos;

Para obter apenas o pedido mais recente de cada cliente, coloque essa consulta em CTE ou subconsulta e filtre posicao = 1 externamente.

Funções de janela são avaliadas depois do WHERE, por isso o alias não pode ser filtrado diretamente na mesma camada em SQL portátil.

LAG e soma acumulada

SELECT criado_em, total,
       LAG(total) OVER (ORDER BY criado_em, id) AS total_anterior,
       SUM(total) OVER (
           ORDER BY criado_em, id
           ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS acumulado
FROM pedidos
WHERE status = 'pago';

LAG acessa a linha anterior na ordem definida. O frame explícito com ROWS evita surpresas quando existem valores de ordenação empatados. Sempre inclua desempate determinístico.

UNION, INTERSECT e EXCEPT

UNION combina resultados compatíveis e remove duplicatas; UNION ALL mantém todas as linhas e costuma ser mais barato.

INTERSECT retorna linhas presentes nos dois resultados; EXCEPT, linhas do primeiro que não aparecem no segundo. Quantidade e tipos das colunas devem ser compatíveis.

SELECT email FROM clientes_ativos
UNION ALL
SELECT email FROM leads_novos;

Não use UNION para juntar colunas lado a lado: isso é papel de JOIN. Operações de conjunto empilham linhas verticalmente.

Se duplicatas têm significado, removê-las pode destruir informação.

Consultas com datas e intervalos

SELECT id, total, criado_em
FROM pedidos
WHERE criado_em >= TIMESTAMP '2026-08-01 00:00:00'
  AND criado_em <  TIMESTAMP '2026-09-01 00:00:00';

O intervalo semiaberto inclui todo agosto sem inventar o último milissegundo.

Em sistemas com fuso horário, defina se a coluna armazena instante global ou horário local e converta nas bordas corretas.

Aplicar uma função à coluna filtrada pode dificultar índice; comparar limites geralmente é mais eficiente.

Paginação com OFFSET ou cursor

LIMIT com OFFSET é simples, mas o banco ainda pode percorrer e descartar muitas linhas em páginas profundas.

Alterações entre requisições também deslocam resultados. Paginação por cursor usa os últimos valores ordenados e escala melhor quando existe ordem estável.

SELECT id, criado_em, total
FROM pedidos
WHERE (criado_em, id) < (TIMESTAMP '2026-08-15 12:00:00', 9000)
ORDER BY criado_em DESC, id DESC
LIMIT 20;

A comparação de tuplas é suportada pelo PostgreSQL; outros bancos podem exigir condição expandida.

O cursor precisa incluir todos os campos de ordenação e deve ser tratado como dado opaco pela API.

Consultas parametrizadas e segurança

Nunca monte SQL concatenando texto fornecido pelo usuário. Parâmetros mantêm o comando separado dos valores.

A OWASP recomenda prepared statements com consultas parametrizadas como defesa principal contra SQL injection, além de menor privilégio e allow-list para partes que não aceitam parâmetros.

SELECT id, nome, cidade
FROM clientes
WHERE cidade = $1 AND ativo = $2;

A sintaxe do marcador varia pela biblioteca: $1, ? ou parâmetros nomeados. Não coloque aspas manualmente ao redor do marcador.

Nomes de tabela, coluna e direção normalmente não aceitam bind; mapeie opções externas para uma lista fixa definida no código.

Use uma conta de aplicação com somente os privilégios necessários. Parametrização impede que o valor vire código, mas não substitui autorização: um usuário válido ainda não deve consultar registros de outro cliente.

Como melhorar o desempenho das consultas

Otimize com evidência. Primeiro confirme a correção, reproduza com volume representativo e registre duração, linhas, frequência e concorrência.

Uma consulta executada uma vez por noite permite decisões diferentes de outra chamada milhares de vezes por minuto.

Leia o plano com EXPLAIN

EXPLAIN mostra o plano estimado; EXPLAIN ANALYZE executa a consulta e acrescenta tempos e contagens reais.

A documentação atual do PostgreSQL sobre EXPLAIN descreve scans, custos, estimativas e ressalvas. Não use ANALYZE despreocupadamente em comandos que alteram dados.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, cliente_id, total
FROM pedidos
WHERE cliente_id = 42 AND status = 'pago';

Compare linhas estimadas e reais, observe scans repetidos, grandes ordenações e leituras de buffers.

Um sequential scan não é automaticamente ruim: pode ser ideal quando a tabela é pequena ou o filtro retorna grande parte dela.

Índices ajudam, mas têm custo

Índices aceleram buscas, junções e ordenações compatíveis, mas ocupam espaço e tornam inserções e atualizações mais caras. A ordem das colunas em índice composto deve refletir filtros e ordenação reais.

Um índice em (cliente_id, status) não é equivalente a dois índices isolados em todos os planos.

Antes de criar, verifique se já existe índice semelhante, quantas linhas o filtro retorna e se estatísticas estão atualizadas.

Depois compare o plano e a latência. Remova índices redundantes somente após confirmar dependências e carga.

Padrões que deixam consultas lentas

• Buscar todas as colunas e linhas quando a aplicação usa poucas.
• Aplicar função ou conversão à coluna filtrada sem necessidade.
• Usar curinga no início de buscas textuais amplas.
• Executar uma consulta por item em loop, conhecido como problema N+1.
• Combinar tabelas sem condição completa e multiplicar linhas.
• Ordenar grandes resultados que serão descartados.
• Paginar profundamente com OFFSET.
• Criar índices sem medir seletividade e custo de escrita.
• Executar relatórios pesados no banco transacional em horário crítico.
• Confiar em desempenho medido apenas com uma base pequena.

ORMs podem introduzir consultas N+1 ou selecionar colunas desnecessárias.

O comparativo de ORMs para Node.js ajuda a entender conveniência e controle, mas o plano gerado pelo banco continua sendo a referência de desempenho.

Como depurar uma consulta SQL

1. Escreva a pergunta e a granularidade esperada: uma linha por cliente, pedido ou item.
2. Execute apenas a tabela principal e conte as linhas.
3. Adicione cada JOIN separadamente e monitore multiplicação ou perda.
4. Aplique filtros um por vez e teste limites, NULL e datas.
5. Remova agregações para enxergar as linhas que as alimentam.
6. Compare amostras com registros conhecidos e cálculos manuais.
7. Use chaves e contagens distintas para conferir cardinalidade.
8. Leia o plano apenas depois de validar o resultado.
9. Crie um teste de regressão com casos pequenos e representativos.

Quando o total está errado, quase sempre existe uma diferença de granularidade ou filtro. COUNT(*), COUNT(DISTINCT chave) e uma seleção das chaves envolvidas ajudam a localizar o ponto em que as linhas se multiplicam.

Boas práticas de legibilidade e manutenção

• Liste uma coluna por linha em consultas extensas.
• Use aliases consistentes e nomes de resultado que expressem significado.
• Qualifique colunas ambíguas com o alias da tabela.
• Formate JOIN e condição ON juntos.
• Comente a razão de uma regra incomum, não a sintaxe óbvia.
• Evite números mágicos; centralize regras compartilhadas.
• Versione consultas usadas por aplicações e relatórios críticos.
• Registre SGBD e versão quando o dialeto for relevante.
• Use transações apropriadas para leituras que exigem consistência.
• Mantenha dados sensíveis fora de logs de consulta.

SQL bem formatado reduz revisão e risco. Ferramentas automáticas ajudam, mas um nome como valor_total_pago comunica mais que soma. Prefira intenção explícita a abreviações difíceis.

8 exercícios para praticar consultas SQL

1. Liste clientes ativos por cidade e nome.
2. Encontre pedidos pagos de um intervalo de datas, do maior para o menor.
3. Calcule quantidade e valor total de pedidos por status.
4. Mostre todos os clientes e a quantidade de pedidos pagos, incluindo zero.
5. Encontre clientes sem nenhum pedido usando NOT EXISTS.
6. Calcule o total dos itens por pedido e compare com pedidos.total.
7. Retorne o pedido mais recente de cada cliente com ROW_NUMBER.
8. Analise uma consulta com EXPLAIN e documente o efeito de um índice.

Para praticar escrita de dados separadamente, use os guias de inserção, atualização e exclusão em SQL.

Mantenha exercícios de modificação em banco descartável e use transações para verificar o efeito antes de confirmar.

Checklist antes de usar uma consulta

• A pergunta e a granularidade do resultado estão claras.
• As colunas selecionadas são realmente necessárias.
• Filtros tratam NULL, limites e datas corretamente.
• Cada JOIN possui condição completa e cardinalidade conhecida.
• Agregações não somam valores duplicados.
• A ordenação possui desempate determinístico.
• Parâmetros externos não são concatenados ao SQL.
• A conta do banco tem o menor privilégio necessário.
• O resultado foi conferido com casos conhecidos.
• O plano foi medido com volume representativo quando desempenho importa.
• A consulta funciona no SGBD e na versão do projeto.
• Há teste ou documentação para regras críticas.

Perguntas frequentes

SQL é igual em todos os bancos?

A base é semelhante, mas os dialetos divergem em tipos, datas, funções, paginação, JSON, upsert e recursos avançados.

Escreva SQL portátil quando isso trouxer valor, mas não evite um recurso seguro do banco apenas por uma migração hipotética. Documente a dependência.

SELECT * é sempre errado?

Não. É útil em exploração rápida e diagnósticos controlados. Em aplicações, APIs e relatórios persistentes, prefira colunas explícitas para reduzir tráfego, exposição e acoplamento ao esquema.

Em EXISTS, SELECT 1 comunica melhor a intenção.

JOIN é sempre melhor que subconsulta?

Não. Bancos modernos transformam diversas formas lógicas em planos parecidos.

EXISTS expressa bem existência; subconsulta escalar atende comparação; JOIN combina colunas. Escolha a forma correta e legível, depois use o plano e medições.

Ainda preciso aprender SQL usando ORM?

Sim. O ORM facilita mapeamento e operações comuns, mas você precisa interpretar consultas, transações, cardinalidade, índices e planos para diagnosticar desempenho e correção.

Saber SQL permite reconhecer N+1, carregamento excessivo e filtros executados na aplicação em vez do banco.

Conclusão: consulte dados com intenção e medição

Consultas SQL evoluem de SELECT simples para filtros, agregações, junções, CTEs e funções de janela.

A complexidade deve acompanhar a pergunta, não o desejo de usar mais recursos. Defina a granularidade, construa em etapas e valide cada transformação.

Antes de publicar, parametrizar valores, limitar privilégios e medir o plano são tão importantes quanto obter o resultado correto.

Uma consulta legível, segura e testada continua sendo uma das ferramentas mais valiosas para desenvolvimento backend, análise de dados e operação de sistemas.