Muita gente aprende SQL, descobre filtros, joins e agregacoes, e ainda assim tropeca em um detalhe pequeno que quebra analises inteiras: = NULL.
O problema e que ele nao quebra com erro de sintaxe. Ele quebra silenciosamente. A query roda. O resultado volta. E voce passa a desconfiar da base, quando na verdade o problema esta na logica.
NULL nao e zero, string vazia ou falso
No SQL, NULL representa ausencia de valor ou valor desconhecido. Ele nao e 0, nao e '' e nao e false.
Essa diferenca parece teorica, mas ela muda completamente a forma como o banco avalia condicoes.
Se voce escreve:
SELECT *
FROM clientes
WHERE email = NULL;
o banco nao entende isso como “me traga clientes sem email”. Ele entende como uma comparacao com algo desconhecido. E comparacoes com algo desconhecido nao viram true.
Na pratica, esse filtro tende a nao retornar o que voce queria.
O jeito certo: IS NULL
Para encontrar linhas sem valor, use IS NULL.
SELECT *
FROM clientes
WHERE email IS NULL;
Para buscar o contrario, use IS NOT NULL.
SELECT *
FROM clientes
WHERE email IS NOT NULL;
Essa e a regra basica que evita um monte de confusao em analise, validacao e limpeza de dados.
Onde esse erro aparece no trabalho real
O erro com NULL costuma aparecer em quatro cenarios bem comuns:
- filtro de colunas cadastrais, como email, telefone, cidade ou categoria;
CASE WHENpara classificar dados faltantes;- joins em que parte das chaves nao casa;
- validacoes de qualidade de dados antes de publicar uma metrica.
Exemplo de classificacao:
CASE
WHEN telefone IS NULL THEN 'sem telefone'
ELSE 'com telefone'
END
Se voce trocar IS NULL por = NULL, a classificacao passa a falhar justamente nas linhas mais importantes para o diagnostico.
O bug fica pior depois de um LEFT JOIN
Esse erro aparece bastante depois de LEFT JOIN.
Quando voce junta duas tabelas e quer descobrir o que nao encontrou correspondencia do lado direito, e 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 padrao retorna pedidos sem pagamento associado.
Se alguem escreve pg.pedido_id = NULL, o diagnostico deixa de funcionar. E ai nasce uma conclusao errada sobre a integridade da base.
NULL tambem afeta condicoes compostas
Outro ponto importante: NULL nao atrapalha so filtros simples. Ele tambem 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 expressao mal escrita com comparacao direta a NULL. O problema nao vai ser apenas tecnico. Ele vai contaminar a leitura de negocio.
Quando a metrica fica errada por causa disso, o time comeca a discutir a operacao, nao a query.
COALESCE ajuda, mas nao resolve tudo
COALESCE e util quando voce quer substituir NULL por um valor padrao.
SELECT COALESCE(canal, 'desconhecido') AS canal_ajustado
FROM vendas;
Isso e excelente para exibir, agrupar ou evitar saidas quebradas. Mas nao muda a regra principal: para verificar ausencia de valor, use IS NULL.
Pense assim:
IS NULLresponde “o valor esta ausente?”COALESCEresponde “o que eu mostro se o valor estiver ausente?”
As duas coisas se complementam, mas nao se substituem.
Um checklist de 30 segundos
Antes de salvar ou publicar sua query, confira:
- Voce usou
IS NULLeIS NOT NULLem vez de= NULL? - Depois de um
LEFT JOIN, voce testou as colunas da tabela da direita corretamente? - Seu
CASE WHENtrata valores ausentes de forma explicita? - Se houve
COALESCE, ele esta mascarando um problema que deveria ser medido?
Esse mini checklist evita varios falsos alarmes de dados.
Resumo direto
NULL e uma das coisas mais simples de explicar e uma das mais frequentes de errar no SQL.
Se a pergunta e “essa coluna esta vazia?”, a resposta tecnica correta quase sempre passa por IS NULL.
Aprender isso cedo vale muito porque o erro de = NULL nao faz barulho. Ele so entrega analise errada com cara de analise certa.
