Pular para o conteúdo principal

Questão de Banco de Dados — Consultas e Comandos em SQL — CESPE / CEBRASPE 2024

Banco de DadosConsultas e Comandos em SQL
Código
ce403622
Banca
CESPE / CEBRASPE
Órgão
MPO
Ano
2024
Cargo
APO ( )
Considerando aspectos da análise de desempenho e otimização de consultas SQL, julgue o próximo item.   A consulta   SELECT * FROM Produtos WHERE TipoProd = ‘1’;   é mais eficiente que a consulta a seguir.   SELECT * FROM Produtos WHERE TipoProd = CAST (@char AS INT);
  1. CCerto
  2. EErrado
Revelar gabarito e comentário

GabaritoE — Errado

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Otimização de Consultas SQL: Literais vs. Conversão de Tipos

Gabarito: Errado. A afirmação de que a consulta com literal '1' é sempre mais eficiente que a que usa CAST(@char AS INT) é incorreta, pois a eficiência depende de fatores como a existência de índices, o tipo real da coluna TipoProd e a capacidade do otimizador de converter a constante. A consulta com literal pode até ser mais eficiente em alguns casos, mas não é uma regra geral.

A análise de desempenho de consultas SQL envolve diversos fatores, e a comparação entre uma condição com literal e outra com conversão explícita de tipo não pode ser reduzida a uma afirmação categórica. O otimizador de consultas do banco de dados é responsável por escolher o plano de execução mais eficiente, e ele pode tratar a conversão de uma constante de forma diferente da conversão de uma variável. Vamos entender os detalhes.

Primeiro, é importante distinguir entre constante e variável. Na primeira consulta, '1' é uma constante literal. Na segunda, @char é uma variável (parâmetro) que será convertida para inteiro em tempo de execução. O otimizador pode avaliar a constante '1' e convertê-la para o tipo da coluna TipoProd durante a compilação do plano, tornando a comparação direta. Já com a variável, a conversão pode ser feita em cada execução, o que pode impedir o uso eficiente de índices.

No entanto, a afirmação de que a primeira é sempre mais eficiente é falsa. Se a coluna TipoProd for do tipo VARCHAR e houver um índice nela, a consulta com '1' pode usar o índice diretamente. Mas se a coluna for do tipo INT, o otimizador pode converter '1' para 1 e usar o índice. Já na segunda consulta, se @char for uma variável, o otimizador pode não saber seu valor em tempo de compilação e pode não conseguir usar o índice de forma eficiente, especialmente se a conversão for feita na coluna (o que é um erro comum). Mas se a conversão for feita na variável (como no exemplo), o otimizador pode ainda usar o índice se a coluna for do tipo certo.

A questão explora a diferença entre SARGable (Search ARGumentable) e non-SARGable predicates. Um predicado é SARGable quando pode ser usado para buscar em um índice. Por exemplo, WHERE coluna = '1' é SARGable se coluna for do mesmo tipo ou se a constante for convertida. Já WHERE CAST(coluna AS INT) = 1 é non-SARGable, pois a função na coluna impede o uso do índice. No caso apresentado, a conversão é feita na variável (CAST(@char AS INT)), não na coluna, então o predicado pode ser SARGable. Mas a eficiência ainda depende de outros fatores.

Outro ponto é que a conversão de tipos pode ter custo computacional, mas é mínimo em comparação com o custo de varredura de tabela. A diferença de desempenho entre as duas consultas, se houver, é mais provavelmente devido à capacidade do otimizador de usar índices do que ao custo da conversão em si.

Portanto, a afirmação é uma generalização indevida. A banca tenta fazer o candidato acreditar que qualquer operação com função (CAST) é mais lenta que uma comparação direta, mas isso não é verdade absoluta. O otimizador pode otimizar ambas as consultas de forma semelhante, e a eficiência real depende do contexto.

Predicado SARGable
  • 1Função na coluna
    • Impede uso de índice
  • 2Função na variável/constante
    • Permite uso de índice
  • 3Comparação das consultas
    • Literal '1'
      • Otimizador converte em tempo de compilação
      • Pode usar índice
    • CAST(@char AS INT)
      • Conversão na variável
      • Pode usar índice
  • 4Eficiência depende de
    • Tipo da coluna
    • Existência de índice
    • Decisão do otimizador
LEVEL · soulevel.com.br

Item — ❌ Errado

A afirmação de que a primeira consulta é mais eficiente que a segunda é incorreta porque não há garantia de que isso ocorra. A eficiência depende de:

  • Tipo da coluna TipoProd: se for INT, a primeira consulta com '1' pode exigir conversão implícita, enquanto a segunda já converte a variável. Se for VARCHAR, a primeira é direta, mas a segunda também pode ser otimizada.

  • Existência de índice: se houver índice em TipoProd, ambas as consultas podem usá-lo, desde que o predicado seja SARGable. A conversão na variável não impede o uso do índice.

  • Otimizador: o banco pode converter a constante '1' para o tipo da coluna em tempo de compilação, tornando as duas consultas equivalentes em termos de plano de execução.

A pegadinha está em assumir que qualquer uso de função (CAST) torna a consulta mais lenta. Na verdade, o que torna uma consulta lenta é a impossibilidade de usar índices, e isso ocorre quando a função é aplicada à coluna, não à constante/variável.

NÃO CAIA NESSA!

A banca explora a confusão entre aplicar a função na coluna (o que impede o uso de índice) e aplicar na variável (o que não impede). No exemplo, o CAST é aplicado em @char, não em TipoProd, então o predicado pode ser SARGable. O candidato que não percebe isso marca "Certo" por achar que qualquer conversão é ruim.

Gabarito: Errado

Link permanente: /questoes/ce403622