Auditor Fiscal de Tributos Municipais - Auditoria e Fiscalização - 2º Dia
Sobre a otimização (tuning) de consultas em bancos de dados relacionais, avalie as afirmações apresentadas a seguir:I. Consultas com múltiplas condições de seleção conectadas pelo operador lógico OR podem não utilizar índices eficientemente e podem ser otimizadas dividindo-as em uma união (UNION) de consultas separadas.II. O uso desnecessário da cláusula DISTINCT pode ser evitado sem alterar o resultado em alguns casos, o que é benéfico, pois DISTINCT frequentemente causa uma operação de ordenação onerosa.III. Consultas aninhadas correlacionadas são sempre mais eficientes do que suas versões não aninhadas ou reescritas como JOINs, pois o SGBD otimiza sua execução avaliando a subconsulta apenas uma vez.IV. Expressões aritméticas ou comparações envolvendo valores NULL ou substrings em cláusulas WHERE podem, em alguns casos, impedir que o otimizador de consulta utilize índices relevantes.É correto o que se afirma em:
AI, II, III e IV.
BI, II e IV, apenas.
CIII, apenas.
DII, III e IV, apenas.
EI, apenas.
Revelar gabarito e comentário▾
GabaritoB — I, II e IV, apenas.
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 em bancos de dados relacionais
Gabarito: letra B. Estão corretas as afirmativas I, II e IV. A afirmativa III está incorreta, pois consultas aninhadas correlacionadas são geralmente menos eficientes que suas versões reescritas como JOINs, uma vez que a subconsulta é avaliada repetidamente para cada linha da consulta externa, e não apenas uma vez.
Item I — ✅ Correta
Consultas com múltiplas condições de seleção conectadas por OR podem não utilizar índices eficientemente, pois o otimizador muitas vezes precisa percorrer toda a tabela. Uma técnica comum de tuning é reescrever a consulta como uma UNION de consultas separadas, cada uma com uma condição que pode usar um índice individualmente, melhorando o desempenho.
Item II — ✅ Correta
A cláusula DISTINCT, quando desnecessária (por exemplo, se a consulta já garante unicidade por chave primária ou por condições), deve ser evitada, pois sua execução frequentemente envolve uma operação de ordenação ou hashing, que é onerosa. Removê-la sem alterar o resultado traz ganho de desempenho.
Item III — ❌ Incorreta
A afirmativa está equivocada. Consultas aninhadas correlacionadas (subconsultas que referenciam colunas da consulta externa) tendem a ser menos eficientes, pois a subconsulta é executada para cada linha da consulta externa. Reescritas como JOINs ou subconsultas não correlacionadas geralmente permitem que o otimizador encontre planos de execução mais eficientes, processando a subconsulta uma única vez.
Item IV — ✅ Correta
Expressões envolvendo NULL (como IS NULL ou IS NOT NULL) ou funções sobre strings (como SUBSTRING, LEFT) em cláusulas WHERE podem impedir que o otimizador utilize índices existentes. Por exemplo, um índice em uma coluna não é usado se a condição for coluna IS NULL (depende do SGBD, mas muitos não usam) ou se houver uma função aplicada à coluna (ex.: WHERE LOWER(nome) = 'joão'), pois o índice armazena os valores originais.