Muita gente aprende SQL, descobre filtros, joins e agregações, e ainda assim tropeça em um detalhe pequeno que quebra análises inteiras: = NULL.
O problema é que ele não quebra com erro de sintaxe. Ele quebra silenciosamente. A query roda. O resultado volta. E você passa a desconfiar da base, quando na verdade o problema está na lógica.
NULL não é zero, string vazia ou falso
No SQL, NULL representa ausência de valor ou valor desconhecido. Ele não é 0, não é '' e não é false.
Essa diferença parece teórica, mas ela muda completamente a forma como o banco avalia condições.
Se você escreve:
SELECT *
FROM clientes
WHERE email = NULL;
o banco não entende isso como “me traga clientes sem email”. Ele entende como uma comparação com algo desconhecido. E comparações com algo desconhecido não viram true.
Na prática, esse filtro tende a não retornar o que você queria.
O jeito certo: IS NULL
Para encontrar linhas sem valor, use IS NULL.
SELECT *
FROM clientes
WHERE email IS NULL;
Para buscar o contrário, use IS NOT NULL.
SELECT *
FROM clientes
WHERE email IS NOT NULL;
Essa é a regra básica que evita um monte de confusão em análise, validação e limpeza de dados.
Onde esse erro aparece no trabalho real
O erro com NULL costuma aparecer em quatro cenários bem comuns:
- filtro de colunas cadastrais, como email, telefone, cidade ou categoria;
CASE WHENpara classificar dados faltantes;- joins em que parte das chaves não casa;
- validações de qualidade de dados antes de publicar uma métrica.
Exemplo de classificação:
CASE
WHEN telefone IS NULL THEN 'sem telefone'
ELSE 'com telefone'
END
Se você trocar IS NULL por = NULL, a classificação passa a falhar justamente nas linhas mais importantes para o diagnóstico.
O bug fica pior depois de um LEFT JOIN
Esse erro aparece bastante depois de LEFT JOIN.
Quando você junta duas tabelas e quer descobrir o que não encontrou correspondência do lado direito, é comum filtrar por uma coluna da tabela direita.
SELECT p.pedido_id
FROM pedidos p
LEFT JOIN pagamentos pg
ON p.pedido_id = pg.pedido_id
WHERE pg.pedido_id IS NULL;
Esse padrão retorna pedidos sem pagamento associado.
Se alguém escreve pg.pedido_id = NULL, o diagnóstico deixa de funcionar. E aí nasce uma conclusão errada sobre a integridade da base.
NULL também afeta condições compostas
Outro ponto importante: NULL não atrapalha só filtros simples. Ele também mexe em AND, OR e CASE.
Imagine:
WHERE status = 'ativo'
AND data_cancelamento IS NULL
Essa regra faz sentido para achar clientes ativos sem cancelamento registrado.
Agora imagine uma expressão mal escrita com comparação direta a NULL. O problema não vai ser apenas técnico. Ele vai contaminar a leitura de negócio.
Quando a métrica fica errada por causa disso, o time começa a discutir a operação, não a query.
COALESCE ajuda, mas não resolve tudo
COALESCE é útil quando você quer substituir NULL por um valor padrão.
SELECT COALESCE(canal, 'desconhecido') AS canal_ajustado
FROM vendas;
Isso é excelente para exibir, agrupar ou evitar saídas quebradas. Mas não muda a regra principal: para verificar ausência de valor, use IS NULL.
Pense assim:
IS NULLresponde “o valor está ausente?”COALESCEresponde “o que eu mostro se o valor estiver ausente?”
As duas coisas se complementam, mas não se substituem.
Um checklist de 30 segundos
Antes de salvar ou publicar sua query, confira:
- Você usou
IS NULLeIS NOT NULLem vez de= NULL? - Depois de um
LEFT JOIN, você testou as colunas da tabela da direita corretamente? - Seu
CASE WHENtrata valores ausentes de forma explícita? - Se houve
COALESCE, ele está mascarando um problema que deveria ser medido?
Esse mini checklist evita vários falsos alarmes de dados.
Resumo direto
NULL é uma das coisas mais simples de explicar e uma das mais frequentes de errar no SQL.
Se a pergunta é “essa coluna está vazia?”, a resposta técnica correta quase sempre passa por IS NULL.
Aprender isso cedo vale muito porque o erro de = NULL não faz barulho. Ele só entrega análise errada com cara de análise certa.
