Analista de Controle Externo-Auditoria de Tecnologia da Informação
Para melhorar o desempenho de consultas SQL, sempre que possível,
Anão se deve utilizar stored procedures para consultas realizadas com frequência em ambientes de rede.
Bdeve-se utilizar DISTINCT ao invés de EXISTS quando se fizer joins que envolvam tabelas com relacionamento um-para-muitos.
Cdeve-se trocar o operador EXISTS ou NOT EXISTS por IN ou NOT IN.
Ddeve-se utilizar funções nas consultas em lugar do operador LIKE.
Edeve-se substituir o UNION por UNION ALL.
Revelar gabarito e comentário▾
GabaritoE — deve-se substituir o UNION por UNION ALL.
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: Melhorando desempenho de consultas
Gabarito: letra E. Para melhorar o desempenho de consultas SQL, sempre que possível, deve-se substituir UNION por UNION ALL, pois UNION executa uma operação de eliminação de duplicatas (equivalente a um SELECT DISTINCT), o que adiciona custo computacional desnecessário quando não há ou não importam duplicatas. O material de apoio explica que "O operador UNION, por default, executa o equivalente a um SELECT DISTINCT no result set final", enquanto "UNION ALL... não executa o SELECT DISTINCT e apresenta todas as linhas, inclusive as duplicadas". Portanto, UNION ALL é mais rápido.
A banca cobra o conhecimento de otimização de consultas, especialmente o custo de operações de conjunto.
1UNIONElimina duplicatas (SELECT DISTINCT)
2UNION ALLMais rápido, sem DISTINCT
3ResultadoSubstituir UNION por UNION ALL
LEVEL · soulevel.com.br
Alternativa A — ❌ Incorreta
Afirma que "não se deve utilizar stored procedures para consultas realizadas com frequência em ambientes de rede". Na verdade, stored procedures podem melhorar o desempenho porque reduzem o tráfego de rede (o comando é executado no servidor) e permitem reutilização de planos de execução. Portanto, é recomendado seu uso para consultas frequentes.
Alternativa B — ❌ Incorreta
Propõe "utilizar DISTINCT ao invés de EXISTS quando se fizer joins que envolvam tabelas com relacionamento um-para-muitos". O uso de DISTINCT costuma ser mais custoso que EXISTS, pois DISTINCT precisa ordenar ou hashear todos os registros para eliminar duplicatas, enquanto EXISTS para na primeira ocorrência. Em joins um-para-muitos, EXISTS geralmente é mais eficiente.
Alternativa C — ❌ Incorreta
Sugere "trocar o operador EXISTS ou NOT EXISTS por IN ou NOT IN". Depende do contexto. O IN pode ser ineficiente com subconsultas grandes, pois o SGBD pode precisar materializar a lista. EXISTS, por outro lado, é geralmente mais eficiente para subconsultas correlacionadas. Não há regra única; é preciso analisar o caso.
Alternativa D — ❌ Incorreta
Indica "utilizar funções nas consultas em lugar do operador LIKE". Funções em colunas (ex.: UPPER(coluna)) podem impedir o uso de índices, tornando a consulta mais lenta. LIKE, quando usado com padrões que não começam com %, pode aproveitar índices. Portanto, substituir LIKE por funções não é recomendado para performance.
Alternativa E — ✅ Correta ⟵ GABARITO
Substituir UNION por UNION ALL é uma prática de otimização. UNION elimina linhas duplicadas implicitamente, realizando uma operação de DISTINCT. Se as duplicatas não são um problema ou já são tratadas, UNION ALL evita esse passo extra, sendo mais rápido. O material de apoio confirma: "O operador UNION, por default, executa o equivalente a um SELECT DISTINCT no result set final. Este processo é executado mesmo que não haja registros duplicados." e "O operador UNION ALL tem a mesma funcionalidade do UNION, porém, não executa o SELECT DISTINCT no result set final e apresenta todas as linhas, inclusive as linhas duplicadas."
NÃO CAIA NESSA!
O candidato pode pensar que UNION é melhor porque deduplica, mas a questão foca em desempenho. Se não houver necessidade de eliminar duplicatas (ou se elas já foram tratadas), UNION ALL é mais rápido. A banca explora essa confusão entre funcionalidade e custo.