O que é SQL e para que serve? Guia para quem vem do Excel

Se você já passou a manhã cruzando duas planilhas com PROCV para descobrir quais clientes compraram no mês, você já sabe o que é SQL — só não sabe ainda. SQL é uma linguagem para fazer perguntas a um banco de dados. Aquilo que você resolve com filtro, tabela dinâmica e fórmula, o SQL resolve com um comando de poucas linhas — e sem travar o computador quando a base tem meio milhão de registros.

O que significa SQL (e por que ele é mais fácil do que parece)

SQL é a sigla de Structured Query Language, ou Linguagem de Consulta Estruturada. Repare na palavra do meio: consulta. É a chave para entender por que tanta gente do administrativo aprende SQL sem nunca ter programado.

SQL não é uma linguagem de programação completa. Você não constrói um aplicativo, um site ou um sistema inteiro com ela. Ela é uma linguagem declarativa: você descreve o resultado que quer e o banco se vira para achar o caminho mais rápido. Em Python ou Java, você diz como fazer, passo a passo. Em SQL, você diz o que quer.

Isso muda o esforço de aprendizado: o vocabulário essencial cabe em uma dezena de palavras de inglês do dia a dia — select (selecione), from (de), where (onde), count (conte), sum (some).

O que é um banco de dados relacional

Pense em uma pasta de trabalho do Excel. Cada aba é uma tabela. Cada linha é um registro (um cliente, um pedido). Cada coluna é um campo (nome, cidade, valor).

A diferença aparece em duas ideias:

• Chave primária — a coluna que identifica cada linha sem repetir. Na tabela clientes, é o id. Dois clientes podem se chamar “Ana Ribeiro”; o id não repete nunca.
• Chave estrangeira — a coluna de uma tabela que aponta para a chave primária de outra. Na tabela pedidos, o campo cliente_id guarda o código do cliente que fez aquele pedido.

É assim que duas tabelas se conversam: pedidos.cliente_id aponta para clientes.id.

E por que não guardar tudo numa planilha só? Porque ela obriga você a repetir nome, CNPJ e endereço do cliente em cada linha de pedido. Quando o endereço muda, são 300 linhas para corrigir — e você vai esquecer algumas. Aí a mesma empresa vira “Móveis Silva”, “MOVEIS SILVA” e “Moveis Silva ME”, e o relatório sai errado. O banco relacional resolve isso guardando cada informação em um lugar só e ligando as tabelas pelo código.

Os comandos essenciais

SELECT e FROM — escolher colunas

SELECT nome, cidade, telefone
FROM clientes;

Traduzindo: “selecione as colunas nome, cidade e telefone da tabela clientes”. O * traz todas as colunas, mas evite o hábito: em tabela grande é lento e desnecessário.

WHERE — o filtro do Excel

SELECT nome, cidade, limite_credito
FROM clientes
WHERE cidade = 'Campinas'
  AND limite_credito > 5000;

Isso é exatamente o filtro da planilha, escrito. Texto vai entre aspas simples; número, não.

ORDER BY — ordenar

SELECT nome, limite_credito
FROM clientes
ORDER BY limite_credito DESC;

DESC é do maior para o menor; ASC, o padrão, é o inverso.

LIMIT / TOP — cortar o resultado

Aqui aparece a primeira diferença entre bancos:

-- MySQL, PostgreSQL e SQLite
SELECT nome, limite_credito
FROM clientes
ORDER BY limite_credito DESC
LIMIT 10;

-- SQL Server
SELECT TOP 10 nome, limite_credito
FROM clientes
ORDER BY limite_credito DESC;

COUNT, SUM, AVG, MIN e MAX — as agregações

SELECT
  COUNT(*)   AS total_pedidos,
  SUM(valor) AS faturamento,
  AVG(valor) AS ticket_medio,
  MIN(valor) AS menor_pedido,
  MAX(valor) AS maior_pedido
FROM pedidos;

São CONT.NÚM, SOMA, MÉDIA, MÍNIMO e MÁXIMO com outro nome.

GROUP BY — a tabela dinâmica do SQL

Esse é o conceito que mais trava iniciante, e a comparação certa destrava: GROUP BY é a tabela dinâmica. Você escolhe o campo que vira “linha” do resumo e a conta que vira “valor”.

SELECT
  cliente_id,
  COUNT(*)   AS qtd_pedidos,
  SUM(valor) AS total_gasto
FROM pedidos
GROUP BY cliente_id
ORDER BY total_gasto DESC;

O resultado deixa de ser uma linha por pedido e passa a ser uma linha por cliente. A regra de ouro: toda coluna do SELECT que não está dentro de uma função de agregação precisa aparecer no GROUP BY.

HAVING — filtrar depois de agrupar

SELECT
  cliente_id,
  SUM(valor) AS total_gasto
FROM pedidos
WHERE data_pedido >= '2026-01-01'
GROUP BY cliente_id
HAVING SUM(valor) > 10000
ORDER BY total_gasto DESC;

A diferença é de momento: o WHERE filtra antes de agrupar (descarta pedidos anteriores a 2026) e o HAVING filtra depois (descarta clientes cujo total ficou abaixo de 10 mil). Por isso HAVING pode usar SUM() e WHERE não.

JOIN — o PROCV do SQL

É a habilidade que mais diferencia quem sabe SQL de quem só copia consulta pronta.

SELECT
  c.nome,
  p.data_pedido,
  p.valor
FROM pedidos AS p
INNER JOIN clientes AS c
        ON c.id = p.cliente_id
ORDER BY p.data_pedido DESC;

O INNER JOIN traz só o que existe nos dois lados: pedidos que têm cliente cadastrado. Já o LEFT JOIN mantém tudo da tabela da esquerda, mesmo sem correspondência:

SELECT
  c.nome,
  COUNT(p.id) AS qtd_pedidos
FROM clientes AS c
LEFT JOIN pedidos AS p
       ON p.cliente_id = c.id
GROUP BY c.nome
ORDER BY qtd_pedidos ASC;

A diferença aparece na prática: com INNER JOIN, o cliente que nunca comprou some do relatório. Com LEFT JOIN, ele aparece com zero — e é justamente ele que a área comercial quer ver.

INSERT, UPDATE e DELETE

INSERT INTO clientes (nome, cidade, limite_credito)
VALUES ('Ana Ribeiro', 'Sorocaba', 3000);

UPDATE clientes
SET limite_credito = 5000
WHERE id = 42;

DELETE FROM clientes
WHERE id = 42;

⚠️ O alerta mais importante deste texto: um UPDATE ou DELETE sem WHERE altera ou apaga a tabela inteira — e não existe Ctrl+Z. O hábito profissional é simples: escreva primeiro como SELECT, olhe o que aparece, e só então troque o começo do comando mantendo o mesmo WHERE. Em banco de produção se trabalha com transação e backup, e ninguém mexe sozinho. Estagiário que derrubou tabela em produção não é lenda: é história real e comum.

-- 1) confira o que seria afetado
SELECT id, nome, limite_credito
FROM clientes
WHERE cidade = 'Campinas';

-- 2) só então troque o início, mantendo o mesmo WHERE
UPDATE clientes
SET limite_credito = 5000
WHERE cidade = 'Campinas';

Onde SQL entra no dia a dia de quem não é programador

• Relatório e extração de dado — parar de pedir “exporta pra mim” e tirar o dado você mesmo.
• Sistema de gestão (ERP) — quase todo ERP guarda os dados em banco relacional; relatório customizado nasce de uma consulta.
• BI e dashboard — Power BI, Looker Studio e Metabase se alimentam de consultas SQL.
• Controle de estoque — giro, ruptura, produto parado, divergência de inventário.
• Conciliação financeira — cruzar o que foi faturado com o que foi recebido.
• Marketing e CRM — recortar a base por comportamento de compra.

Em muita empresa, a pessoa do administrativo que sabe SQL vira quem todo mundo procura quando aparece uma pergunta que o relatório padrão não responde. Isso não é promessa de promoção: é uma constatação sobre o tipo de tarefa que passa a chegar até você.

SQL x Excel: quando cada um serve

Um não substitui o outro. O fluxo mais comum é consultar com SQL e finalizar no Excel: o banco entrega o recorte limpo, a planilha faz a apresentação.

Os “sabores” de SQL

MySQL, PostgreSQL, SQL Server, Oracle e SQLite são bancos diferentes, e cada um tem seu dialeto. Mas o núcleo é o mesmo: SELECT, WHERE, ORDER BY, GROUP BY, HAVING e JOIN funcionam em todos. A diferença aparece nos detalhes — LIMIT contra TOP, funções de data, concatenação de texto. Por isso aprender um serve para todos: a migração é ajuste de particularidade, não recomeço.

LGPD: você vai ver dado pessoal real

Quem consulta banco corporativo enxerga CPF, endereço, telefone, salário e, dependendo do setor, dado de saúde. A LGPD trata isso como responsabilidade sua também:

• Menor privilégio — peça acesso só às tabelas que a sua função exige.
• Não extraia mais do que a tarefa pede. Se o pedido é o total por região, não leve a lista nominal junto.
• Dado real não vai para planilha pessoal, e-mail particular, pen drive nem ferramenta de inteligência artificial. Colar uma base com CPF em um chat de IA é vazamento.
• Cuidado com ambiente de teste alimentado com dado de produção — falha comum e séria. O correto é usar dado anonimizado.

Como aprender de verdade

1. Instale um banco leve no seu computador e um cliente para escrever consultas.
2. Use uma base de exemplo com clientes, produtos e pedidos, em vez de tabelas de duas linhas.
3. Resolva perguntas reais, não sintaxe solta: “quais os 10 clientes que mais compraram no ano?”, “qual produto encalhou no último trimestre?”, “quais clientes não compram há 90 dias?”.

Esse terceiro item é o que separa quem sabe SQL de quem decorou comandos. Traduzir a pergunta do negócio para tabela, filtro e agrupamento é mais difícil do que escrever o comando — e é exatamente a parte que só a prática ensina.

Se a lógica fez sentido, o próximo passo é escrever suas primeiras consultas com calma, do zero, com exercícios — e isso dá para começar hoje, de graça.