Questão de Banco de Dados — Consultas e Comandos em SQL — CESPE / CEBRASPE 2024
Banco de Dados›Consultas e Comandos em SQL
Código
ce403621
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 Empregado WHERE Nome = @P OR Login = @P; é menos eficiente que a seguinte consulta. SELECT _ FROM Empregado WHERE Nome = @P UNION SELECT _ FROM Empregado WHERE Login = @P;
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoC — Certo
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”.
SQL – Otimização de Consultas: OR vs. UNION
Gabarito: Certo. A consulta com OR é, em geral, menos eficiente que a versão com UNION, porque o otimizador de consultas tem mais dificuldade em usar índices separados para cada condição quando elas estão combinadas por OR em um único WHERE. A versão com UNION permite que o banco de dados explore cada condição de forma independente, potencialmente usando um índice para Nome e outro para Login, e depois combine os resultados. Essa é uma técnica clássica de otimização de consultas SQL.
A questão aborda um dos pontos mais importantes da otimização de consultas: como o otimizador do banco de dados lida com diferentes formas de escrever a mesma consulta lógica. A primeira consulta usa um OR para combinar duas condições na cláusula WHERE. A segunda usa UNION para combinar os resultados de duas consultas separadas, cada uma com uma condição simples. Embora ambas retornem o mesmo resultado (assumindo que não há duplicatas, ou que as duplicatas são aceitáveis), o desempenho pode ser drasticamente diferente.
O motivo da diferença de desempenho está na forma como o otimizador de consultas planeja a execução. Quando você usa OR, o otimizador pode ter que fazer uma varredura completa da tabela (table scan) se não conseguir usar um índice de forma eficiente. Isso ocorre porque ele precisa encontrar todas as linhas que satisfazem a condição Nome = @P OU a condição Login = @P. Se houver um índice em Nome e outro em Login, o otimizador pode tentar usar ambos e combinar os resultados, mas essa operação de combinação (chamada de bitmap OR ou index merge) nem sempre é a mais eficiente, e em muitos SGBDs ela não é nem mesmo considerada, levando a uma varredura completa.
Por outro lado, a consulta com UNION é estruturalmente mais simples para o otimizador. Ele pode executar a primeira consulta (WHERE Nome = @P) usando o índice em Nome, e a segunda consulta (WHERE Login = @P) usando o índice em Login. Cada consulta é otimizada separadamente, e os resultados são combinados no final. Isso geralmente resulta em um plano de execução mais eficiente, especialmente em tabelas grandes.
É importante notar que o UNION elimina linhas duplicadas por padrão, o que adiciona um custo extra de ordenação ou hashing. Se você sabe que não há duplicatas (por exemplo, se Nome e Login são colunas únicas), pode usar UNION ALL, que é ainda mais eficiente porque não tenta eliminar duplicatas. No entanto, mesmo com o custo de eliminação de duplicatas, o UNION geralmente supera o OR em termos de desempenho quando há índices disponíveis.
A pegadinha aqui é que muitos candidatos podem pensar que a consulta com OR é mais eficiente porque é mais curta e parece mais simples. No entanto, a eficiência de uma consulta não está relacionada à sua complexidade sintática, mas sim ao plano de execução que o otimizador gera. A forma como a consulta é escrita pode influenciar diretamente a capacidade do otimizador de usar índices, e é isso que a questão está testando.
NÃO CAIA NESSA!
A banca explora a intuição de que "menos código = mais rápido". Na verdade, a consulta com OR pode forçar uma varredura completa da tabela, enquanto o UNION permite que o otimizador use índices separados para cada condição. O candidato que não conhece o comportamento do otimizador tende a marcar "Errado", achando que a consulta com OR é mais eficiente por ser mais direta.
Consulta
Estratégia do Otimizador
Uso de Índices
Eficiência
WHERE Nome = @P OR Login = @P
Dificuldade em combinar condições com OR; pode recorrer a table scan
Limitado; depende de index merge (nem sempre disponível)
Menor
WHERE Nome = @P UNION WHERE Login = @P
Executa cada condição separadamente e combina resultados
Pode usar índice em Nome e outro em Login
Maior
Alternativa C — ✅ Certo ⟵ GABARITO
A afirmação está correta. A consulta com OR é, de fato, menos eficiente que a versão com UNION na maioria dos casos, especialmente quando há índices nas colunas Nome e Login. O UNION permite que o otimizador use um plano de execução que explora cada condição separadamente, potencialmente usando índices, enquanto o OR pode levar a uma varredura completa da tabela. Essa é uma técnica bem conhecida de otimização de consultas, e a banca está correta ao afirmar que a primeira consulta é menos eficiente.