Antes de escrever a query: como estruturar o problema

Chega o pedido: “me manda os clientes que estão comprando menos”. Você abre o editor, escreve SELECT, e trava.

Não travou por falta de SQL. Travou porque o pedido ainda não é uma pergunta respondível.

Comece pelo fim: como é uma linha do resultado?

Antes de qualquer código, descreva uma linha da tabela que você quer entregar. Em voz alta, em português:

“Uma linha por cliente, com o quanto ele comprou nos últimos 30 dias e o quanto comprou nos 30 anteriores.”

Essa frase já contém quase tudo:

O grão — uma linha por cliente. É o que vai no GROUP BY.
As métricas — dois valores somados. É o que vai no SELECT.
O recorte — duas janelas de 30 dias. É o que vai no WHERE.

Sem essa frase, você está escrevendo query para uma tabela que ainda não existe na sua cabeça.

Depois: de onde vem cada coisa

Com a linha definida, cada pedaço vira uma pergunta de origem:

Quanto comprou → tabela de pedidos
Quem é o cliente → tabela de clientes
O que conta como “comprando” → pedido cancelado entra?

Repare que a terceira não tem resposta técnica. É regra de negócio, e é a que muda o número. Se você não perguntar agora, vai descobrir depois — quando alguém disser que o relatório está errado.

O grão é o que mais derruba query

Quase todo número inflado tem a mesma origem: você juntou uma tabela de grão diferente e não percebeu.

Um pedido tem vários itens. Se você junta pedidos com itens e soma o valor do pedido, cada pedido é contado uma vez por item. O total dobra, triplica, e a query não dá erro nenhum.

O teste é uma frase: “depois desse JOIN, uma linha é o quê?” Se a resposta mudou e você não queria que mudasse, o problema está ali.

Pra lembrar

A ordem que funciona:

Descreva uma linha do resultado
Liste de onde vem cada coluna
Confirme as regras de negócio que mudam o número
Aí sim escreva o SQL

Os três primeiros passos não têm código nenhum — e são onde a query é realmente resolvida. O quarto é digitação.