Perda silenciosa de dados: como um INNER JOIN descarta linhas sem avisar

Em resumo: um INNER JOIN só mantém as linhas que casam dos dois lados. Quando a chave de junção tem furos (nulos, formatos diferentes, registros sem correspondência), ele descarta linhas em silêncio, e o relatório sai com menos dado, sem nenhum aviso. É uma das causas mais comuns de número que "encolheu sem explicação".

Por que o erro é silencioso

INNER JOIN faz exatamente o que promete: devolve só o que casa. O problema é o outro lado. O que não casa some sem reclamar: sem erro, sem log, sem uma linha avisando que sumiu. Se 5% das chaves não batem, você perde 5% dos registros e o total ainda parece plausível. Ninguém vê. O rombo só aparece quando alguém confere linha a linha contra a fonte, e a essa altura o número já rodou em vários relatórios.

Quando isso acontece de verdade

Quatro cenários se repetem. Nenhum dá erro.

• Chave com formato diferente entre as tabelas (espaço, zero à esquerda, maiúscula/minúscula).
• Nulos na chave: não casam com nada.
• Cadastro incompleto: um pedido sem cliente correspondente é descartado.
• Granularidade errada: junção que multiplica linhas (o oposto: dado a mais).

Como detectar e se proteger

1. Conte antes e depois do join. Se o número de linhas caiu, investigue por quê.
2. Compare totais por camada: origem vs. resultado (mesma lógica de achar a diferença no fechamento).
3. Use LEFT JOIN + verificação quando quiser manter tudo e tratar o que não casou.
4. Valide a chave (formato, nulos) antes da junção, parte de um pipeline confiável.

O ponto não é "nunca usar INNER JOIN". É saber o que ele descarta e validar isso de propósito. Faço esse tipo de blindagem em pipelines ETL/ELT. Já rastreei alguns desses sumiços. Se um número encolheu sem explicação, eu ajudo a achar onde ele sumiu.