A coluna que não existe e a junção que duplica

A IA não conhece o seu schema. Ela conhece schemas parecidos com o seu — e a diferença entre os dois é onde mora o número errado.

1. Coluna ou tabela plausível que não existe

Peça uma consulta de churn e é provável que apareça uma coluna data_cancelamento ou ativo. São nomes muito comuns — e podem não existir no seu banco, onde a mesma informação talvez esteja em status = 3 ou numa tabela de eventos.

Esse é o erro bom: o banco reclama. Custa dois minutos.

2. Junção que multiplica linhas

SELECT p.cliente_id, SUM(p.valor) AS total
FROM pedidos p
JOIN pedido_itens i ON i.pedido_id = p.id
WHERE p.criado_em >= '2026-01-01'
GROUP BY p.cliente_id;

SELECT p.cliente_id, SUM(p.valor) AS total
FROM pedidos p
WHERE p.criado_em >= '2026-01-01'
GROUP BY p.cliente_id;

-- Se precisar de dado do item, agregue o item primeiro:
SELECT p.cliente_id, SUM(p.valor) AS total, SUM(i.qtd) AS itens
FROM pedidos p
JOIN (
    SELECT pedido_id, SUM(quantidade) AS qtd
    FROM pedido_itens GROUP BY pedido_id
) i ON i.pedido_id = p.id
WHERE p.criado_em >= '2026-01-01'
GROUP BY p.cliente_id;

A diferença: A regra: junção para muitos antes de agregação infla a agregação. Sempre que houver JOIN com SUM/COUNT, pergunte quantas linhas a junção produz por linha da tabela principal.

-- Antes de confiar em qualquer agregação com JOIN:
SELECT COUNT(*) FROM pedidos WHERE criado_em >= '2026-01-01';
-- 3.412

SELECT COUNT(*) FROM pedidos p
JOIN pedido_itens i ON i.pedido_id = p.id
WHERE p.criado_em >= '2026-01-01';
-- 11.847  ← a junção triplicou; qualquer SUM aqui está inflado

3. NULL que some da conta em silêncio

A última linha é a que mais surpreende: WHERE status <> 5 não traz os pedidos com status nulo. Quem espera "todos menos os cancelados" recebe menos que isso.

4. A janela de data errada

O mesmo problema que existe em código existe aqui, e com impacto maior: BETWEEN com dois extremos fechados conta a fronteira duas vezes em faixas consecutivas, e comparar uma coluna datetime com uma data pura perde as horas do último dia.

WHERE criado_em BETWEEN '2026-03-01' AND '2026-03-31' exclui tudo o que aconteceu depois da meia-noite do dia 31 — quase um dia inteiro de dados. Use sempre >= inicio AND < proximo_inicio.

5. Amostra tratada como população

Um LIMIT 1000 colocado para a consulta rodar rápido durante o desenvolvimento tem o hábito de sobreviver até a versão final. E LIMIT sem ORDER BY não devolve "mil linhas quaisquer": devolve as mil que o banco achou primeiro, que costumam ser as mais antigas ou as de uma partição só.

Escreva a consulta para responder: [pergunta em linguagem natural]

Schema real (colado do banco):
[cole o CREATE TABLE ou a saída de DESCRIBE das tabelas envolvidas]

O que você precisa saber antes:
- Volume: [tabela X tem N linhas]
- Cardinalidade: [um pedido tem 1..N itens; um cliente tem 0..N pedidos]
- Qualidade: [coluna Y tem ~3% de nulos; status 3 = cancelado, 7 = estornado]
- Fuso: [criado_em em UTC; o negócio opera em America/Sao_Paulo]

Antes da consulta, responda:
1) Quais linhas você está incluindo e excluindo, e por quê
2) Se algum JOIN pode multiplicar linhas, e como você evitou
3) O que acontece com os NULLs nas colunas que você usou

Depois, a consulta. E uma segunda consulta de conferência, que valide
o resultado por outro caminho.