COUNT(DISTINCT) é uma das funções mais úteis do SQL. E também uma das mais usadas para esconder problema sem querer.
Isso acontece muito no trabalho real: a contagem explode depois de um JOIN, alguém coloca DISTINCT, o número volta a “parecer certo” e a análise segue em frente. O perigo é que, muitas vezes, o erro estrutural continua ali.
Esta Dica Rápida serve para separar dois cenários: quando COUNT(DISTINCT) é exatamente a métrica certa e quando ele só está cobrindo um problema que você ainda não entendeu.
Como usar este checklist
Para cada item abaixo, responda quatro perguntas antes de fechar a query:
- o que validar;
- qual é o sinal verde;
- qual erro comum aparece;
- qual ação rápida ajuda a corrigir.
Se você não consegue explicar por que o DISTINCT entrou na contagem, ainda não deveria confiar no número final.
Checklist: COUNT(DISTINCT) resolve ou mascara?
1) A unidade da análise está explícita
O que validar: definir com clareza o que representa “1” na métrica: um cliente, um pedido, uma sessão, um lead ou outro identificador.
Sinal verde: você consegue dizer em uma frase qual entidade está sendo contada e qual coluna representa essa entidade.
Erro comum: usar COUNT(DISTINCT) antes de decidir se a métrica deveria contar linhas, eventos ou entidades únicas.
Ação rápida: escreva a pergunta de negócio em linguagem simples e identifique qual chave responde essa pergunta.
2) O JOIN não multiplicou linhas sem você perceber
O que validar: comparar o volume antes e depois do JOIN e revisar a cardinalidade entre as tabelas.
Sinal verde: a multiplicação de linhas é esperada e explicável, ou então o volume permanece coerente com a granularidade original.
Erro comum: juntar uma tabela de pedidos com uma tabela de itens, inflar a base e usar COUNT(DISTINCT id_pedido) só para “normalizar” a resposta.
Ação rápida: rode uma query de diagnóstico com COUNT(*), COUNT(DISTINCT chave) e amostra de registros para enxergar onde a duplicidade entra.
3) A repetição é legítima ou é sujeira de dado
O que validar: entender se linhas repetidas representam eventos reais do negócio ou duplicidade indevida de coleta/processamento.
Sinal verde: você sabe explicar por que uma entidade aparece mais de uma vez e em que contexto isso é esperado.
Erro comum: tratar toda repetição como erro técnico, ou o oposto, assumir que toda repetição é normal e esconder tudo com DISTINCT.
Ação rápida: separar os casos em dois grupos: repetição operacional legítima e duplicidade anômala. Só depois decidir a métrica.
4) A lógica da métrica pede entidade única mesmo?
O que validar: confirmar se o objetivo da análise é contar pessoas/objetos únicos ou medir volume de ocorrências.
Sinal verde: existe aderência direta entre a pergunta e a função. Exemplo: “quantos clientes compraram?” pede unicidade; “quantos pedidos foram feitos?” pode não pedir.
Erro comum: usar COUNT(DISTINCT cliente_id) em qualquer painel porque “cliente único” parece mais sofisticado, mesmo quando o indicador correto era quantidade de transações.
Ação rápida: escreva lado a lado duas versões da métrica, uma por ocorrência e outra por entidade única, e valide qual delas responde melhor ao problema.
5) O DISTINCT entrou no lugar certo da query
O que validar: revisar se a desduplicação deveria acontecer na contagem final ou antes, em uma CTE/subquery com a granularidade já corrigida.
Sinal verde: o ponto de desduplicação é coerente com o desenho da query e reduz ambiguidade.
Erro comum: empilhar DISTINCT no SELECT final enquanto a base intermediária continua misturando granularidades.
Ação rápida: materialize uma CTE com a chave esperada por linha e só depois faça a agregação final.
6) Você consegue explicar a diferença entre com e sem DISTINCT
O que validar: medir o delta entre COUNT(*), COUNT(coluna) e COUNT(DISTINCT coluna) no mesmo recorte.
Sinal verde: a diferença entre as contagens é conhecida e faz sentido para a lógica do dado.
Erro comum: aceitar o resultado com DISTINCT sem investigar por que as outras contagens divergem tanto.
Ação rápida: manter um bloco temporário de auditoria na query para comparar as três leituras antes de publicar o número em dashboard ou relatório.
7) A correção está na modelagem, não só na consulta
O que validar: avaliar se o problema recorrente vem de tabela mal modelada, ingestão duplicada ou chave pouco confiável.
Sinal verde: você não depende de remendo manual em toda análise parecida.
Erro comum: resolver no SQL de hoje um problema que vai reaparecer amanhã em outra métrica.
Ação rápida: registrar a causa raiz e abrir ajuste em modelagem, ETL ou governança de chaves quando o erro for estrutural.
Quando COUNT(DISTINCT) é a escolha certa
Há muitos casos em que a função é exatamente o que você quer:
- clientes únicos que compraram em um período;
- usuários únicos impactados por uma campanha;
- pedidos únicos após um
JOINcom tabela de itens, quando a pergunta continua sendo sobre pedidos; - leads únicos que avançaram para uma etapa do funil.
O ponto não é evitar DISTINCT. O ponto é impedir que ele vire anestesia para dado mal entendido.
O teste mais importante
Se alguém perguntar “por que essa query usa COUNT(DISTINCT)?”, sua resposta deveria ser objetiva.
Não basta dizer “porque sem isso o número explode”. A resposta madura é outra: qual entidade você está contando, por que ela pode repetir na base e por que a unicidade é a regra correta para aquela métrica.
Quando essa explicação existe, o DISTINCT está sob controle. Quando ela não existe, você tem um número aparentemente limpo em cima de uma lógica ainda frágil.
Se quiser aprofundar este tema, estes conteúdos complementam este checklist:
