A ordem em que o SQL realmente executa sua query (e por que isso muda tudo)

Você escreve a query nesta ordem:

SELECT cliente, SUM(valor) AS total
FROM pedidos
WHERE estado = 'SP'
GROUP BY cliente
HAVING SUM(valor) > 1000
ORDER BY total DESC

Mas o banco não executa nessa ordem. E entender a ordem real explica uma porção de erros que parecem inexplicáveis.

A ordem real

O SQL executa mais ou menos assim:

1. FROM — de qual tabela vêm os dados
2. WHERE — filtra as linhas (antes de agrupar)
3. GROUP BY — agrupa o que sobrou
4. HAVING — filtra os grupos (depois de agrupar)
5. SELECT — escolhe e calcula as colunas
6. ORDER BY — ordena o resultado final

Repara: SELECT, que você escreve primeiro, é quase o último a rodar.

Por que isso importa: o erro do alias

Esse é o erro clássico que a ordem explica na hora:

SELECT valor * 1.1 AS valor_com_taxa
FROM pedidos
WHERE valor_com_taxa > 100   -- ERRO

O banco reclama que valor_com_taxa não existe. Faz sentido: o WHERE roda antes do SELECT, então no momento do filtro esse alias ainda nem foi criado.

A solução é repetir a expressão (ou usar uma subquery/CTE):

SELECT valor * 1.1 AS valor_com_taxa
FROM pedidos
WHERE valor * 1.1 > 100

Por que WHERE e HAVING não são a mesma coisa

Os dois filtram — mas em momentos diferentes:

• WHERE filtra linhas, antes do agrupamento.
• HAVING filtra grupos, depois do agrupamento.

Por isso você não consegue usar SUM(valor) > 1000 no WHERE: a soma do grupo ainda não existe naquele ponto. Ela só existe depois do GROUP BY — território do HAVING.

Pra lembrar

A ordem mental certa é: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.

Quando uma query der um erro “estranho” de coluna que não existe ou filtro que não funciona, releia nessa ordem. Quase sempre o problema é estar usando algo antes da hora em que ele passa a existir.