0Pricing
Coding Interview Prep · Aula

Filtrando por valores calculados

Entenda por que funções em colunas impedem o uso de índices e como entrevistadores investigam esse ponto.

Filtrando por valores calculados é uma aula grátis de Coding Interview Prep no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Coding Interview Prep, e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Coding Interview Prep inclui 4 aulas no total.

Por que esta pergunta diferencia os níveis

A pergunta parece inocente: esta consulta está correta, mas está lenta; por quê? Muitas vezes, a resposta é que a cláusula WHERE envolve uma coluna indexada em uma função. Isso torna o predicado não sargável: o otimizador não pode mais usar o índice e precisa examinar cada linha.

Esta lição explica a sargabilidade, mostra as reescritas que os entrevistadores esperam e aborda onde um filtro calculado realmente deve ficar.

Sargável em uma definição

Sargável (argumento de busca ABLE) significa que um predicado pode usar um índice para buscar diretamente as linhas correspondentes. A regra geral é: a coluna indexada deve aparecer isolada em um dos lados da comparação, não escondida dentro de uma função ou expressão.

  • Sargável: col = 5, col > 100, col LIKE 'abc%'
  • Não sargável: FUNC(col) = 5, col + 1 > 100

O antipadrão de função na coluna

Aqui, o objetivo é encontrar pedidos feitos em 2024. Envolver a coluna em YEAR() força o mecanismo a calcular o ano para cada uma das linhas antes de poder fazer a comparação, portanto o índice em order_date se torna inútil.

A consulta retorna a resposta correta, mas examina a tabela inteira. Em uma tabela grande, essa é a diferença entre milissegundos e minutos.

-- non-sargable: function on the indexed column
SELECT *
FROM orders
WHERE YEAR(order_date) = 2024;

Reescreva como um intervalo

A solução é deixar order_date isolada e expressar a condição como um intervalo semiaberto. Agora, o índice em order_date pode buscar diretamente o início de 2024 e parar em 2025.

O resultado é o mesmo, mas com uma varredura de intervalo do índice em vez de uma varredura completa. Essa reescrita de intervalo é a correção de sargabilidade mais cobrada em entrevistas.

-- sargable: column stays bare
SELECT *
FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date <  '2025-01-01';

Aritmética na coluna

O mesmo problema aparece na aritmética. WHERE salary + bonus > 100000 ou WHERE price * 0.9 < 50 fazem cálculos na coluna e bloqueiam o índice.

Mova os cálculos para o lado da constante sempre que possível: reescreva price * 0.9 < 50 como price < 50 / 0.9. O literal é calculado uma vez, e price permanece isolada e indexável.

-- before: math on the column (non-sargable)
WHERE price * 0.9 < 50
-- after: math on the constant (sargable)
WHERE price < 50 / 0.9

A variante da busca sem distinção entre maiúsculas e minúsculas

WHERE LOWER(email) = 'a@b.com' não é sargável em relação a um índice simples em email, porque o e-mail de cada linha é convertido primeiro para minúsculas.

Há duas soluções para produção: armazenar uma cópia normalizada em minúsculas e indexá-la, ou criar um índice funcional em LOWER(email) para que a própria expressão seja indexada. Mencionar a opção de índice funcional demonstra experiência prática.

-- functional index makes the expression sargable
CREATE INDEX idx_email_lower ON users (LOWER(email));
SELECT * FROM users WHERE LOWER(email) = 'a@b.com';

Quando você realmente precisa de um cálculo

Às vezes, o filtro realmente depende de um valor calculado para o qual não existe uma reescrita como intervalo, por exemplo, ao filtrar por uma proporção. Ainda assim, você não pode referenciar um nome alternativo de SELECT em WHERE, porque WHERE é avaliado antes da lista de SELECT.

Assim, você pode repetir a expressão em WHERE ou envolver a consulta em uma subconsulta / CTE e filtrar a coluna calculada na consulta externa.

SELECT *
FROM (
  SELECT *, revenue / NULLIF(visits, 0) AS rev_per_visit
  FROM stats
) t
WHERE t.rev_per_visit > 2.5;

Agregações ficam em HAVING, não em WHERE

Um cálculo que é uma agregação não pode ficar em WHERE, porque WHERE filtra linhas individuais antes que o agrupamento aconteça. WHERE SUM(amount) > 1000 é um erro.

Os filtros de agregação ficam em HAVING, que é executado depois de GROUP BY. Saber qual cláusula enxerga o cálculo é, por si só, uma pergunta frequente sobre a ordem de execução.

SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000;

Como os entrevistadores avaliam isso

Eles mostram uma consulta lenta com uma função aplicada a uma coluna e pedem que você a torne rápida sem alterar o resultado. Sua abordagem:

  • Identifique a função aplicada à coluna como não sargável
  • Reescreva para manter a coluna isolada (intervalo ou cálculo do lado da constante)
  • Se não houver uma reescrita, proponha um índice funcional ou uma coluna calculada armazenada

Mencionar EXPLAIN para confirmar que o plano mudou de uma varredura sequencial para uma varredura de índice completa a resposta.

Consciência das compensações

Seja equilibrado: índices e índices funcionais aceleram as leituras, mas tornam as gravações mais lentas e consomem armazenamento. Em uma tabela pequena, uma varredura completa é aceitável, e adicionar um índice seria esforço desperdiçado.

A resposta de alguém experiente é condicional: se esta coluna for grande e for filtrada com frequência dessa forma, torne o predicado sargável ou adicione um índice funcional; caso contrário, deixe como está. Em entrevistas, o contexto é mais importante do que o dogmatismo.

Índices funcionais tornam um cálculo sargável

Às vezes, é realmente necessário filtrar por um valor transformado — por exemplo, em uma correspondência que ignore maiúsculas e minúsculas. Em vez de desistir dos índices, crie um índice de expressão (funcional) usando exatamente a expressão pela qual você filtra.

  • Assim, o otimizador pode usar o índice mesmo quando uma função envolve a coluna.
  • A expressão do índice deve corresponder exatamente à expressão do predicado.
-- index the expression you filter on
CREATE INDEX idx_users_lower_email ON users (lower(email));

-- now this predicate stays sargable
SELECT * FROM users WHERE lower(email) = 'amy@example.com';

Verificação rápida

Identifique qual predicado o otimizador pode indexar.

Recapitulação

Principais conclusões:

  • Um predicado é sargável quando a coluna indexada aparece isolada, não dentro de uma função ou operação aritmética
  • Reescreva YEAR(col) = 2024 como um intervalo semiaberto; mova os cálculos para o lado da constante
  • Para expressões inevitáveis, use um índice funcional ou uma coluna calculada armazenada
  • Você não pode usar um nome alternativo de SELECT em WHERE; as agregações ficam em HAVING

A pergunta clássica envolve uma consulta lenta; a correção clássica é manter a coluna isolada.

Perguntas Frequentes

A aula “Filtrando por valores calculados” é grátis?

Sim — o texto completo de “Filtrando por valores calculados” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Coding Interview Prep, atualize para CoddyKit PRO. O curso de Coding Interview Prep inclui 4 aulas no total.

O que vou aprender em “Filtrando por valores calculados”?

Entenda por que funções em colunas impedem o uso de índices e como entrevistadores investigam esse ponto. Você pratica Coding Interview Prep com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.

Preciso ter experiência prévia para começar Coding Interview Prep?

Nenhuma experiência prévia é necessária. Coding Interview Prep no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.

Quanto tempo leva a aula “Filtrando por valores calculados”?

A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.

Posso escrever e executar código nesta aula de Coding Interview Prep?

Sim. Cada aula de Coding Interview Prep inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.

Todas as aulas deste curso

  1. Precedência de AND/OR e uso de parênteses
  2. BETWEEN, IN e limites inclusivos
  3. LIKE, curingas e escape
  4. Filtrando por valores calculados
← Voltar para Coding Interview Prep