SQL WHERE: filtre linhas com AND, OR e NULL

A cláusula SQL WHERE filtra linhas de uma tabela por condição. Em uma consulta SQL com WHERE, a linha só corresponde quando o predicado é avaliado como TRUE; resultados FALSE e NULL/UNKNOWN são excluídos. Essa lógica de três valores é a origem mais comum de comportamentos inesperados do WHERE com valores NULL.

Exemplo de cláusula SQL WHERE para filtrar linhas

Saída:

A saída aparecerá aqui...

Saída:

+---------+-------------+-------+
| nome    | categoria   | preco |
+---------+-------------+-------+
| Teclado | Eletrônicos | 49.99 |
| Mouse   | Eletrônicos | 25.0  |
+---------+-------------+-------+
2 row(s)

Como este exemplo funciona

  1. CREATE TABLE e INSERT criam uma tabela produtos com quatro linhas em duas categorias.
  2. A cláusula SQL WHERE categoria = 'Eletrônicos' AND preco < 100 combina duas condições com AND: ambas precisam ser TRUE para a linha aparecer.
  3. “Monitor” está em Eletrônicos, mas custa 299.00, então a condição de preço o elimina. “Caderno” falha na verificação de categoria. Só “Teclado” e “Mouse” satisfazem os dois predicados.

O que é uma cláusula SQL WHERE?

Uma cláusula SQL WHERE é um filtro booleano aplicado a cada linha individualmente. O banco de dados avalia a expressão para cada linha candidata e mantém apenas aquelas em que o resultado é TRUE. Qualquer expressão que retorne FALSE ou NULL é descartada. WHERE atua antes de GROUP BY e funções de agregação, o que o diferencia de HAVING.

Erros comuns em cláusulas SQL WHERE

Erro: comparar uma coluna com NULL usando =.

Errado:

WHERE categoria = NULL

Certo:

WHERE categoria IS NULL

Por quê: = NULL é avaliado como UNKNOWN, e WHERE filtra linhas UNKNOWN. Use IS NULL ou IS NOT NULL.

Erro: misturar AND e OR sem parênteses.

Errado:

WHERE categoria = 'Escritório' OR categoria = 'Eletrônicos' AND preco < 50

Certo:

WHERE (categoria = 'Escritório' OR categoria = 'Eletrônicos') AND preco < 50

Por quê: AND tem precedência sobre OR, então parênteses são necessários para corresponder à sua intenção.

WHERE vs HAVING

WHEREHAVING
Filtra linhas individuais antes do agrupamentoFiltra grupos após a agregação
Não pode referenciar funções de agregaçãoPode referenciar COUNT, SUM etc.
Reduz linhas enviadas ao GROUP BYReduz grupos no resultado final

Regra: use WHERE para excluir linhas antes da agregação e HAVING para excluir grupos depois dela. Filtrar cedo com WHERE reduz o trabalho da etapa de agregação.

Considerações de desempenho

Predicados WHERE sobre colunas indexadas transformam varreduras completas de tabela em buscas por índice. Envolver a coluna em uma função, como LOWER(nome) ou DATE(created_at), impede o otimizador de usar o índice; transforme o valor de comparação no lugar disso. Para condições ligadas por AND, um índice composto que segue a ordem das colunas do predicado oferece o melhor desempenho. Condições com OR frequentemente geram varreduras de índice separadas e mescladas, o que costuma ser mais lento do que AND no mesmo índice.

Notas de segurança

Monte condições WHERE com consultas parametrizadas, nunca concatenando entrada do usuário em strings SQL. Para nomes dinâmicos de coluna, valide com uma allow-list estrita. Para listas IN (...), gere placeholders e associe cada valor. Sempre valide comandos UPDATE e DELETE com um SELECT usando a mesma cláusula WHERE antes de executar a escrita.

FAQ

Qual é a diferença entre WHERE e HAVING em SQL?

WHERE filtra linhas antes de GROUP BY; HAVING filtra grupos agregados depois dele. WHERE não pode referenciar funções de agregação como COUNT() ou SUM(). Uma consulta pode usar os dois: WHERE reduz as linhas de entrada e HAVING reduz a saída agrupada.

Por que = NULL não funciona em uma cláusula WHERE?

SQL usa lógica de três valores: TRUE, FALSE e UNKNOWN. Qualquer comparação com NULL retorna UNKNOWN, e WHERE descarta linhas UNKNOWN. Use IS NULL para testar valores NULL. Alguns bancos de dados também oferecem IS NOT DISTINCT FROM para comparações de igualdade seguras com NULL.

A ordem das condições na cláusula WHERE afeta o desempenho?

O padrão SQL não garante ordem de avaliação, e a maioria dos otimizadores reordena predicados internamente. Escreva as condições na ordem mais legível. O desempenho depende de quais colunas são indexadas e de quão seletivo é cada predicado, não da ordem em que você escreve.