Questão de Banco de Dados — Otimização (Tuning) em Banco de Dados — FCC 2026
Banco de Dados›Otimização (Tuning) em Banco de Dados
Código
fc142366
Banca
FCC
Órgão
MPE SE
Ano
2026
Cargo
Ana ( )
Um Ministério Público mantém uma base de dados com investigações em andamento. Um analista precisa identificar rapidamente quais promotores possuem maior volume de investigações registradas e, para isso, escreveu a seguinte consulta SQL: SELECT p.nome, COUNT(i.id_investigacao) AS total_investigacoes FROM Promotor p JOIN Investigacao i ON p.id_promotor = i.id_promotor GROUP BY p.nome ORDER BY total_investigacoes DESC; Considerando a necessidade de otimizar essa consulta em um banco de dados relacional com grande volume de registros, a ação mais adequada (em condições ideais) para melhorar a performance, sem alterar a lógica do resultado, é
Acriar um índice na coluna id_promotor da tabela Investigacao, que é a chave estrangeira utilizada na condição de junção.
Bcriar um índice apenas sobre a coluna nome da tabela Promotor.
Ccriar um índice sobre a coluna total_investigacoes, pois ela é utilizada na ordenação.
Dsubstituir o JOIN por um CROSS JOIN entre as tabelas Promotor e Investigacao e aplicar a condição de junção no WHERE, gerando primeiro o produto cartesiano e filtrando depois.
Eincluir a cláusula DISTINCT no comando SELECT antes do GROUP BY evitando duplicidades.
Revelar gabarito e comentário▾
GabaritoA — criar um índice na coluna id_promotor da tabela Investigacao, que é a chave estrangeira utilizada na condição de junçã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 SQL: Índices e Junções
Gabarito: letra A. A ação mais adequada para otimizar a consulta, sem alterar a lógica do resultado, é criar um índice na coluna id_promotor da tabela Investigacao, pois essa é a chave estrangeira utilizada na condição de junção (JOIN). Esse índice acelera a operação de junção, permitindo que o SGBD localize rapidamente as linhas correspondentes em Investigacao para cada Promotor, em vez de realizar uma varredura completa na tabela.
A otimização de consultas (ou tuning) é o processo pelo qual o SGBD escolhe a estratégia mais eficiente para executar uma consulta SQL. O objetivo é minimizar o tempo de resposta e o consumo de recursos (CPU, memória e I/O). Uma das ferramentas mais poderosas para isso são os índices, estruturas de acesso auxiliares que funcionam como um sumário de um livro: em vez de ler todas as páginas (registros) para encontrar uma informação, o banco consulta o índice e vai direto ao dado desejado.
No caso da consulta apresentada, o ponto crítico é a operação de junção (JOIN) entre as tabelas Promotor e Investigacao. Sem um índice na coluna id_promotor da tabela Investigacao, o SGBD precisaria, para cada promotor, percorrer toda a tabela Investigacao para encontrar as investigações correspondentes. Isso é conhecido como full table scan e é extremamente ineficiente em tabelas com grande volume de dados. Ao criar um índice nessa coluna, o SGBD pode usar uma busca binária para localizar rapidamente as linhas correspondentes, reduzindo drasticamente o custo da junção.
É importante entender que a criação de índices não é uma solução mágica para todos os problemas de performance. Índices consomem espaço em disco e podem diminuir a velocidade de operações de escrita (INSERT, UPDATE, DELETE), pois o índice também precisa ser atualizado. Por isso, a decisão de criar um índice deve ser baseada na análise das consultas mais frequentes e críticas do sistema. No caso em questão, a consulta de agregação com JOIN é claramente um ponto de gargalo, e o índice na chave estrangeira é a medida mais direta e eficaz para otimizá-la.
A pegadinha desta questão está em confundir a coluna que deve ser indexada. Muitos candidatos podem pensar em indexar a coluna nome da tabela Promotor (usada no GROUP BY) ou a coluna total_investigacoes (usada no ORDER BY), mas essas colunas não são o principal gargalo. O gargalo é a junção, e é nela que o índice deve ser criado. Guarde essa distinção: em consultas com JOIN, o índice na chave estrangeira da tabela filha é quase sempre a otimização mais importante.
Critério
Índice em Investigacao(id_promotor) (A)
Índice em Promotor(nome) (B)
Índice em total_investigacoes (C)
O que acelera
Junção (JOIN) entre tabelas
Agrupamento (GROUP BY)
Ordenação (ORDER BY)
Impacto no gargalo principal
Alto — elimina varredura completa da tabela filha
Baixo — não resolve o custo da junção
Nulo — coluna é alias calculado, não indexável
Viabilidade técnica
Sim — coluna real e chave estrangeira
Sim — coluna real, mas benefício marginal
Não — não se cria índice sobre resultado de agregação
Efeito colateral
Acelera a consulta sem alterar resultado
Pode até piorar se o índice não for usado
Impossível de implementar
Recomendação
✅ Gabarito
❌
❌
Alternativa A — ✅ Correta ⟵ GABARITO
Criar um índice na coluna id_promotor da tabela Investigacao é a ação mais adequada. Essa coluna é a chave estrangeira usada na condição de junção (JOIN p.id_promotor = i.id_promotor). O índice permite que o SGBD encontre rapidamente as linhas de Investigacao correspondentes a cada Promotor, evitando uma varredura completa da tabela a cada iteração da junção. Isso acelera significativamente a consulta, especialmente em tabelas com grande volume de dados.
Alternativa B — ❌ Incorreta
Criar um índice apenas sobre a coluna nome da tabela Promotor não é a ação mais adequada. Embora a coluna nome seja usada no GROUP BY, o principal gargalo da consulta é a junção entre as tabelas. Indexar nome pode até ajudar na ordenação do agrupamento, mas não resolve o problema central de performance, que é a busca das investigações para cada promotor. O índice na chave estrangeira da tabela Investigacao é muito mais impactante.
Alternativa C — ❌ Incorreta
Criar um índice sobre a coluna total_investigacoes é inviável, pois essa coluna é um alias criado pela função de agregação COUNT(i.id_investigacao). Índices são criados em colunas de tabelas, não em resultados calculados. Além disso, a ordenação (ORDER BY) é feita após a agregação, e o SGBD pode usar outras estratégias (como ordenação em memória ou em disco) para lidar com isso. O gargalo principal continua sendo a junção, não a ordenação.
Alternativa D — ❌ Incorreta
Substituir o JOIN por um CROSS JOIN e aplicar a condição de junção no WHERE é uma péssima prática de otimização. O CROSS JOIN gera o produto cartesiano entre as duas tabelas, ou seja, combina cada linha de Promotor com cada linha de Investigacao. Em tabelas com grande volume de dados, isso pode gerar um número astronômico de combinações, consumindo enormes quantidades de memória e CPU, antes mesmo de aplicar o filtro no WHERE. Essa abordagem é extremamente ineficiente e deve ser evitada. O JOIN com a condição de junção é a forma correta e otimizada de combinar as tabelas.
Alternativa E — ❌ Incorreta
Incluir a cláusula DISTINCT no comando SELECT antes do GROUP BY é desnecessário e não otimiza a consulta. O GROUP BY já agrupa as linhas por p.nome, e a função COUNT(i.id_investigacao) conta as investigações de cada grupo. Como o GROUP BY já garante que cada grupo apareça apenas uma vez no resultado, o DISTINCT não teria efeito algum, apenas adicionaria uma etapa de processamento desnecessária, potencialmente diminuindo a performance. Além disso, o DISTINCT não resolve o gargalo da junção.