é menos eficiente que a seguinte consulta.
GabaritoC — Certo
Gabarito: Certo (C). A consulta com subconsulta correlacionada é, em geral, menos eficiente que a versão com JOIN, porque a subconsulta correlacionada é reavaliada para cada linha da consulta externa, enquanto o JOIN permite que o otimizador escolha um plano de execução mais eficiente, como o uso de índices e algoritmos de junção otimizados. Essa é a essência da otimização de consultas: o SGBD pode transformar uma consulta em outra equivalente, porém mais barata de executar.
A otimização de consultas é o processo pelo qual o SGBD escolhe o plano de execução mais eficiente para uma consulta SQL. O otimizador analisa as diferentes formas de executar uma consulta — como a ordem das junções, o uso de índices e a estratégia de acesso aos dados — e seleciona aquela com menor custo estimado. Uma das principais diferenças de desempenho entre consultas equivalentes está na forma como subconsultas são processadas.
Uma subconsulta correlacionada é aquela que referencia uma coluna da consulta externa. Por exemplo, uma consulta que verifica, para cada funcionário, se existe um projeto em que ele participa. Nesse caso, a subconsulta interna depende do valor da linha atual da consulta externa, o que impede que ela seja avaliada uma única vez. O SGBD precisa executar a subconsulta para cada linha da consulta externa, o que pode resultar em um custo O(n × m), onde n é o número de linhas da tabela externa e m o custo de avaliar a subconsulta. Isso é drasticamente menos eficiente do que uma junção, que pode ser executada com algoritmos como nested loop join, hash join ou merge join, aproveitando índices e ordenações.
Por outro lado, uma junção (JOIN) combina as linhas de duas tabelas com base em uma condição de correspondência. O otimizador pode escolher a melhor estratégia de junção, como usar um índice na coluna de junção ou ordenar as tabelas para um merge join. Além disso, a junção é uma operação declarativa: o usuário especifica o que quer, e o SGBD decide como executar. Isso dá ao otimizador a liberdade de reordenar as operações e escolher o plano mais eficiente.
Na prática, a diferença de desempenho entre uma subconsulta correlacionada e uma junção equivalente pode ser enorme, especialmente em tabelas grandes. Por exemplo, considere uma tabela FUNCIONARIO com 10.000 linhas e uma tabela DEPARTAMENTO com 100 linhas. Uma consulta correlacionada que, para cada funcionário, verifica se o departamento existe, executaria a subconsulta 10.000 vezes. Uma junção, por outro lado, poderia usar um hash join ou um índice, processando as duas tabelas em uma única passada.
A banca explora exatamente essa distinção: a consulta com subconsulta correlacionada é menos eficiente que a versão com JOIN. O candidato que não conhece o conceito de subconsulta correlacionada pode não perceber a diferença de desempenho, mas o gabarito é claro: a afirmativa está certa.
A afirmativa está correta. A consulta com subconsulta correlacionada é, em geral, menos eficiente que a versão com JOIN, porque a subconsulta é reavaliada para cada linha da consulta externa, enquanto a junção permite que o otimizador escolha um plano de execução mais eficiente. Essa é uma das principais lições de otimização de consultas SQL: preferir junções a subconsultas correlacionadas sempre que possível.
Na prova, quando comparar duas consultas equivalentes, uma com subconsulta correlacionada e outra com JOIN, lembre-se: a subconsulta correlacionada é reavaliada para cada linha da consulta externa, o que a torna menos eficiente. O JOIN permite que o otimizador escolha a melhor estratégia de junção, como hash join ou merge join, aproveitando índices. Essa é uma pegadinha clássica em questões de otimização de SQL.
Gabarito: Certo (C).
Link permanente: /questoes/ce178293