Questão de Banco de Dados — Consultas e Comandos em SQL — CESPE / CEBRASPE 2024
- Código
- ce403622
- Banca
- CESPE / CEBRASPE
- Órgão
- MPO
- Ano
- 2024
- Cargo
- APO ( )
- CCerto
- EErrado
GabaritoE — Errado
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.
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.
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