Docs executáveis de SQLite: GROUP BY e HAVING

Q: Qual a diferença entre WHERE e HAVING no SQLite?

O WHERE filtra linhas individuais antes do agrupamento. Já o HAVING filtra os grupos depois que a agregação acontece. Ou seja, WHERE amount > 100 mantém só as linhas com valor acima de 100, enquanto HAVING SUM(amount) > 100 mantém apenas os grupos cuja soma passa de 100. Funções agregadas como COUNT ou SUM não podem aparecer no WHERE — é justamente para isso que existe o HAVING.

Q: Dá para usar HAVING sem GROUP BY no SQLite?

Dá sim. Sem o GROUP BY, o SQLite trata o resultado inteiro como um único grupo, e o HAVING filtra esse grupo como um todo. A consulta retorna uma linha ou nenhuma. É raro de ver na prática — geralmente, se você tem um HAVING, vai ter um GROUP BY junto.

Q: Como filtrar grupos por COUNT no SQLite?

Coloque a função agregada no HAVING, nunca no WHERE. Por exemplo: SELECT customerid, COUNT() FROM orders GROUP BY customerid HAVING COUNT() > 1 retorna os clientes com mais de um pedido. No SQLite, você ainda pode referenciar um alias da lista do SELECT dentro do HAVING.

GROUP BY agrupa linhas em "baldes"

Funções agregadas como COUNT, SUM e AVG reduzem várias linhas a um único número. O GROUP BY permite fazer isso por categoria — um número por cliente, por mês, por status. Cada valor único (ou combinação de valores) vira uma linha no resultado.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada',   50.00),
    ('Ada',   30.00),
    ('Boris', 80.00),
    ('Boris', 20.00),
    ('Boris', 15.00),
    ('Cleo', 200.00);

SELECT customer, COUNT(*) AS order_count, SUM(amount) AS total
FROM orders
GROUP BY customer;

Três clientes, três linhas no resultado. As seis linhas originais sumiram — foram agrupadas em "baldes" por cliente, com COUNT(*) e SUM(amount) calculados dentro de cada um.

O modelo mental é esse: GROUP BY customer diz "trate todas as linhas com o mesmo cliente como um único grupo". As funções agregadas então atuam separadamente sobre cada grupo.

O que pode entrar no SELECT junto com GROUP BY

É aqui que muita gente tropeça. Quando você usa GROUP BY, toda coluna que aparece no SELECT precisa estar ou no próprio GROUP BY, ou dentro de uma função agregada. Caso contrário, o valor fica ambíguo — afinal, de qual linha do grupo ele deveria vir?

CREATE TABLE sales (
    region TEXT,
    rep TEXT,
    amount REAL
);

INSERT INTO sales VALUES
    ('North', 'Ada', 100),
    ('North', 'Boris', 200),
    ('South', 'Cleo', 150);

-- Isto funciona: region é agrupada, amount é agregada.
SELECT region, SUM(amount) AS total
FROM sales
GROUP BY region;

Se você escrevesse SELECT region, rep, SUM(amount) com GROUP BY region, o SQLite executaria sem reclamar (ele é mais permissivo que outros bancos, que rejeitariam isso na hora), mas o rep seria escolhido de forma arbitrária dentro do grupo. Você acabaria com um nome de representante por região, sem nenhuma garantia de qual seria. Não confie nesse comportamento — agrupe por todas as colunas não agregadas que aparecem no SELECT.

HAVING: filtrando grupos depois da agregação

A diferença entre WHERE e HAVING é simples: WHERE filtra linhas antes do agrupamento, e HAVING filtra grupos depois do agrupamento. É só isso. E é justamente por isso que você não consegue colocar COUNT(*) > 1 dentro de um WHERE — na hora em que o WHERE roda, a contagem ainda nem existe.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada', 50), ('Ada', 30),
    ('Boris', 80), ('Boris', 20), ('Boris', 15),
    ('Cleo', 200);

SELECT customer, COUNT(*) AS order_count
FROM orders
GROUP BY customer
HAVING COUNT(*) > 1;

Cleo só fez um pedido, então o grupo dela é eliminado pelo filtro. Sobram Ada e Boris. A condição é avaliada sobre o valor agregado de cada grupo, e não linha por linha.

No SQLite, dá para usar os apelidos (aliases) das colunas do SELECT diretamente no HAVING:

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL
);

INSERT INTO orders (customer, amount) VALUES
    ('Ada',   50.00),
    ('Ada',   30.00),
    ('Boris', 80.00),
    ('Boris', 20.00),
    ('Boris', 15.00),
    ('Cleo', 200.00);

SELECT customer, SUM(amount) AS total
FROM orders
GROUP BY customer
HAVING total >= 100;

Geralmente, isso fica mais legível do que repetir SUM(amount) na cláusula HAVING.

Diferença entre WHERE e HAVING: usando os dois juntos

As duas cláusulas não são excludentes. O WHERE filtra quais linhas vão participar do agrupamento; o HAVING filtra quais grupos aparecem no resultado final. Na prática, a maioria das consultas usa as duas.

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer TEXT,
    amount REAL,
    status TEXT
);

INSERT INTO orders (customer, amount, status) VALUES
    ('Ada', 50, 'paid'),
    ('Ada', 30, 'refunded'),
    ('Boris', 80, 'paid'),
    ('Boris', 20, 'paid'),
    ('Cleo', 200, 'paid'),
    ('Cleo', 50, 'refunded');

SELECT customer, SUM(amount) AS paid_total
FROM orders
WHERE status = 'paid'
GROUP BY customer
HAVING SUM(amount) > 75;

Leia de cima para baixo, na ordem em que o SQLite executa:

WHERE status = 'paid' — descarta de cara as linhas com reembolso.
GROUP BY customer — agrupa o que sobrou por cliente.
SUM(amount) é calculado dentro de cada grupo.
HAVING SUM(amount) > 75 — mantém só os grupos que passam no filtro.

Boris (80 + 20 = 100) e Cleo (200) sobrevivem. O único pedido pago da Ada foi de 50, que não atinge o limite.

Múltiplas condições e agrupamento por várias colunas

O HAVING aceita os mesmos operadores booleanos do WHERE — AND, OR, NOT — e você pode agrupar por mais de uma coluna para criar subgrupos:

CREATE TABLE sales (
    region TEXT,
    quarter TEXT,
    amount REAL
);

INSERT INTO sales VALUES
    ('North', 'Q1', 100), ('North', 'Q1', 50),
    ('North', 'Q2', 300),
    ('South', 'Q1', 80),
    ('South', 'Q2', 120), ('South', 'Q2', 60);

SELECT region, quarter, SUM(amount) AS total, COUNT(*) AS deals
FROM sales
GROUP BY region, quarter
HAVING SUM(amount) > 100 AND COUNT(*) >= 2;

Cada par (region, quarter) forma um grupo separado. A cláusula HAVING exige que o total seja maior que 100 e que existam pelo menos dois negócios. Só ('North', 'Q1') e ('South', 'Q2') passam nos dois critérios.

Caso prático: encontrando duplicatas

Usar GROUP BY ... HAVING COUNT(*) > 1 é a forma clássica de localizar valores duplicados em uma coluna:

CREATE TABLE users (
    id INTEGER PRIMARY KEY,
    email TEXT
);

INSERT INTO users (email) VALUES
    ('ada@example.com'),
    ('boris@example.com'),
    ('ada@example.com'),
    ('cleo@example.com'),
    ('boris@example.com');

SELECT email, COUNT(*) AS ocorrencias
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Aparecem duas duplicatas. A partir daqui, normalmente você decide se vai mesclar contas, adicionar uma constraint UNIQUE ou limpar os dados — mas a query que faz essa descoberta tem sempre o mesmo formato.

HAVING sem GROUP BY

É raro, mas é permitido. Sem o GROUP BY, todo o resultado é tratado como um único grupo, e o HAVING filtra esse grupo inteiro de uma vez — ou você recebe todos os valores agregados, ou nada:

CREATE TABLE orders (id INTEGER PRIMARY KEY, amount REAL);
INSERT INTO orders (amount) VALUES (50), (30), (80);

SELECT COUNT(*) AS total_orders, SUM(amount) AS revenue
FROM orders
HAVING SUM(amount) > 100;

A linha aparece no resultado porque a soma dá 160. Se você mudar o limite para > 200, a consulta não retorna nenhuma linha. Na prática, você quase sempre vai usar HAVING junto com GROUP BY — mas é bom saber que a linguagem não exige isso.

Resumo rápido

GROUP BY agrupa as linhas em "baldes" por chave; as funções agregadas rodam dentro de cada balde.
Toda coluna do SELECT que não é agregada precisa aparecer no GROUP BY.
WHERE filtra linhas antes do agrupamento; HAVING filtra grupos depois.
Funções agregadas como COUNT(*) e SUM(...) vão no HAVING, nunca no WHERE.
O HAVING aceita múltiplas condições e pode referenciar apelidos definidos no SELECT.

Próximo passo: chaves estrangeiras

Agregar dados de uma única tabela já ajuda bastante, mas a maioria dos esquemas reais espalha as informações por várias tabelas — pedidos aqui, clientes ali, produtos em outro lugar. As chaves estrangeiras são o que conecta essas tabelas e mantém os relacionamentos consistentes. Esse é o assunto do próximo capítulo.

Perguntas frequentes

Qual a diferença entre WHERE e HAVING no SQLite?

O WHERE filtra linhas individuais antes do agrupamento. Já o HAVING filtra os grupos depois que a agregação acontece. Ou seja, WHERE amount > 100 mantém só as linhas com valor acima de 100, enquanto HAVING SUM(amount) > 100 mantém apenas os grupos cuja soma passa de 100. Funções agregadas como COUNT ou SUM não podem aparecer no WHERE — é justamente para isso que existe o HAVING.

Dá para usar HAVING sem GROUP BY no SQLite?

Dá sim. Sem o GROUP BY, o SQLite trata o resultado inteiro como um único grupo, e o HAVING filtra esse grupo como um todo. A consulta retorna uma linha ou nenhuma. É raro de ver na prática — geralmente, se você tem um HAVING, vai ter um GROUP BY junto.

Como filtrar grupos por COUNT no SQLite?

Coloque a função agregada no HAVING, nunca no WHERE. Por exemplo: SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id HAVING COUNT(*) > 1 retorna os clientes com mais de um pedido. No SQLite, você ainda pode referenciar um alias da lista do SELECT dentro do HAVING.

Conceitos relacionados

GROUP BY e HAVING no SQLite: filtrando agregações