Uma área de protocolo e recebimento de processos de um órgão público estadual utiliza um sistema baseado em banco de dados relacional para registrar e acompanhar a tramitação de processos administrativos. Nos horários de pico, quando há grande volume de consultas por número de processo e por interessado, usuários relatam lentidão no atendimento. A equipe técnica analisou o plano de execução da consulta mais utilizada e identificou uso de funções aplicadas diretamente sobre colunas indexadas na cláusula código-fonte WHERE, além de subconsulta correlacionada para recuperar o último andamento do processo. Mesmo existindo índices nas colunas envolvidas, o plano indicou varredura completa de tabela e alto custo estimado. Dado o cenário apresentado, um diagnóstico consistente indica que a
Areescrita da consulta para eliminar funções sobre colunas indexadas e substituir subconsulta correlacionada por junção favorece melhor o plano de execução.
Bsolução prioritária está na ampliação do hardware do servidor, aumentando CPU e memória para absorver o volume de consultas concorrentes.
Ccriação de índices adicionais nas colunas envolvidas na consulta é suficiente para garantir utilização eficiente pelo otimizador.
Ddesnormalização das tabelas envolvidas elimina a necessidade de junções e melhora o desempenho das consultas complexas.
Emigração do banco de dados para solução não relacional é recomendada quando consultas envolvem subconsultas correlacionadas e funções em cláusulas de filtro.
Revelar gabarito e comentário▾
GabaritoA — reescrita da consulta para eliminar funções sobre colunas indexadas e substituir subconsulta correlacionada por junção favorece melhor o plano de execução.
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 A. O diagnóstico correto é que a lentidão decorre de uma consulta mal escrita: funções aplicadas sobre colunas indexadas impedem o uso dos índices (o otimizador não consegue usar o índice porque a coluna está "escondida" dentro de uma função) e a subconsulta correlacionada força uma execução repetida para cada linha da consulta externa. A reescrita da consulta, eliminando as funções sobre as colunas indexadas e substituindo a subconsulta correlacionada por uma junção (JOIN), é a solução mais adequada e favorece um melhor plano de execução.
O problema descrito é clássico em bancos de dados relacionais: o otimizador de consultas depende de estatísticas e da estrutura da consulta para escolher o melhor plano de execução. Quando uma função é aplicada diretamente sobre uma coluna indexada na cláusula WHERE (por exemplo, WHERE UPPER(nome) = 'JOÃO' ou WHERE YEAR(data) = 2024), o índice perde sua utilidade, pois o otimizador não consegue usar a ordem dos valores indexados para buscar diretamente os registros — ele precisa avaliar a função para cada linha, resultando em uma varredura completa da tabela (full table scan). Isso é um dos motivos mais comuns de degradação de desempenho, mesmo com índices existentes.
Além disso, a subconsulta correlacionada é um padrão que pode ser extremamente ineficiente. Nesse tipo de subconsulta, a consulta interna é executada uma vez para cada linha processada pela consulta externa, pois ela referencia uma coluna da consulta externa (correlação). Para recuperar o "último andamento do processo", uma abordagem comum é usar uma subconsulta correlacionada com MAX(data_andamento), o que pode gerar um custo altíssimo em tabelas grandes. A alternativa mais eficiente é reescrever a consulta usando uma junção (JOIN) com uma subconsulta não correlacionada que calcula o último andamento de uma vez, ou usar funções de janela (window functions) como ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...). A reescrita permite que o otimizador escolha um plano de execução muito mais eficiente, como usar índices e junções por hash ou merge.
A questão explora exatamente esse diagnóstico: a equipe identificou as causas técnicas (funções sobre colunas indexadas e subconsulta correlacionada) e o plano de execução mostrou varredura completa e alto custo. A solução não é simplesmente adicionar mais índices (pois eles já existem e não são usados), nem ampliar hardware (que trata o sintoma, não a causa), nem desnormalizar (que pode até piorar a manutenção), nem migrar para NoSQL (que não resolve o problema de uma consulta mal escrita em um banco relacional). A solução correta é reescrever a consulta para que o otimizador possa usar os índices e escolher um plano eficiente.
A pegadinha da banca está em oferecer alternativas que parecem soluções plausíveis (hardware, índices, desnormalização, NoSQL), mas que não atacam a causa raiz identificada no enunciado. O candidato que entende como o otimizador funciona e como a estrutura da consulta afeta o plano de execução reconhece imediatamente que a reescrita é a solução.
Critério
Reescrita da consulta (A)
Ampliar hardware (B)
Criar índices adicionais (C)
Desnormalização (D)
Migração para NoSQL (E)
Ataca a causa raiz (funções em colunas indexadas + subconsulta correlacionada)?
Sim — elimina funções e substitui subconsulta por JOIN
Não — trata sintoma, não a causa
Não — índices já existem e não são usados
Não — não resolve o problema de funções/subconsulta
Não — não resolve consulta mal escrita
Efeito no plano de execução
Permite uso de índices e escolha de JOIN eficiente (hash/merge)
Mantém varredura completa, mesmo com mais recursos
Índices continuam inutilizados
Pode até piorar manutenção, sem garantir uso de índices
Não se aplica a banco relacional
Custo/risco da solução
Baixo — apenas reescrever SQL
Alto — investimento em infraestrutura
Médio — esforço sem benefício garantido
Alto — risco de inconsistência de dados
Altíssimo — mudança drástica de arquitetura
Adequação ao cenário relacional
Total — otimização clássica de SQL
Parcial — melhora geral, mas não resolve
Nenhuma — problema estrutural da consulta
Nenhuma — não ataca a causa
Nenhuma — desnecessária e inadequada
Alternativa A — ✅ Correta ⟵ GABARITO
A reescrita da consulta para eliminar funções sobre colunas indexadas e substituir a subconsulta correlacionada por uma junção é exatamente o que o diagnóstico indica. Ao remover as funções da cláusula WHERE, o otimizador pode usar os índices existentes para acessar diretamente os registros. Ao substituir a subconsulta correlacionada por uma junção (ou por uma subconsulta não correlacionada), o otimizador pode escolher um plano de execução mais eficiente, como um hash join ou merge join, em vez de executar a subconsulta para cada linha. Essa é a abordagem correta para melhorar o desempenho da consulta.
Alternativa B — ❌ Incorreta
Ampliar o hardware (CPU e memória) pode melhorar o desempenho geral do servidor, mas não resolve a causa raiz do problema: a consulta ineficiente. Mesmo com mais recursos, o otimizador continuará escolhendo um plano de execução ruim (varredura completa) porque a estrutura da consulta impede o uso dos índices. A solução de hardware trata o sintoma, não a causa, e pode ser um desperdício de recursos se a consulta não for otimizada.
Alternativa C — ❌ Incorreta
Criar índices adicionais nas colunas envolvidas não resolve o problema, pois os índices já existem e não estão sendo usados. O motivo é que as funções aplicadas sobre as colunas indexadas impedem o uso dos índices, independentemente de quantos índices existam. O otimizador não consegue usar um índice quando a coluna está dentro de uma função, pois ele precisaria avaliar a função para cada valor indexado, o que não é possível com a estrutura do índice. A solução é reescrever a consulta, não criar mais índices.
Alternativa D — ❌ Incorreta
A desnormalização (adicionar redundância controlada ao banco) pode reduzir o número de junções em algumas consultas, mas não é a solução para o problema descrito. O problema é a consulta mal escrita (funções sobre colunas indexadas e subconsulta correlacionada), não a necessidade de junções. A desnormalização pode até piorar a situação, aumentando a complexidade de manutenção e o risco de inconsistência de dados, sem garantir que o otimizador use os índices. A reescrita da consulta é a abordagem correta.
Alternativa E — ❌ Incorreta
Migrar para um banco de dados não relacional (NoSQL) não é recomendado para resolver problemas de consultas ineficientes em um banco relacional. O NoSQL tem características diferentes (esquema flexível, escalabilidade horizontal, etc.), mas não resolve o problema de uma consulta mal escrita. Além disso, o cenário descrito (consultas por número de processo e por interessado, com necessidade de recuperar o último andamento) é típico de um banco relacional, e a migração seria uma mudança drástica e desnecessária. A solução é otimizar a consulta no banco relacional existente.