Questão de Banco de Dados — Índices — FUNDATEC 2025
Banco de Dados›Índices
Código
qg468563
Banca
FUNDATEC
Órgão
BRDE
Ano
2025
Nível
Superior
Cargo
Analista de Sistemas - Subárea Administração de Banco de Dados
Uma query que junta as tabelas Vendas (10.000 linhas) e Clientes (1.000 linhas) está performando mal. Ambas as tabelas têm índices nas colunas de junção (cliente_id). Analisando o plano de execução, o DBA verifica que o otimizador escolheu um Nested Loops Join. Em qual cenário essa escolha é a mais adequada?
AA tabela Vendas é muito maior que a tabela Clientes.
BA query retorna um grande conjunto de resultados (mais de 10% dos dados).
CA tabela Clientes é a driving table e, para cada linha, há poucas correspondências em Vendas usando o índice.
DNão existem índices nas colunas de junção.
EA query precisa ordenar o resultado final por uma coluna das duas tabelas.
Revelar gabarito e comentário▾
GabaritoC — A tabela Clientes é a driving table e, para cada linha, há poucas correspondências em Vendas usando o índice.
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”.
Nested Loops Join e otimização de consultas
Gabarito: letra C. O Nested Loops Join é mais adequado quando a tabela driving (externa) é pequena e, para cada linha dela, há poucas correspondências na tabela interna, especialmente se houver um índice eficiente na coluna de junção da tabela interna. A alternativa C descreve exatamente esse cenário: Clientes (1.000 linhas) como driving table e, para cada cliente, poucas linhas de Vendas (10.000 linhas) acessadas via índice.
A banca testa o conhecimento sobre quando o otimizador escolhe um método de junção específico. O Nested Loops é o mais simples: para cada linha da tabela externa, procura correspondências na interna. Se a tabela externa for pequena e houver índice na interna, o custo é baixo. Caso contrário, outros métodos (Hash Join, Merge Join) são preferíveis.
NÃO CAIA NESSA!
O candidato pode pensar que Nested Loops é sempre ruim com tabelas grandes, mas ele é eficiente quando a tabela driving é pequena e o índice da tabela interna reduz drasticamente o número de acessos. A pegadinha está em confundir o tamanho absoluto das tabelas com a seletividade do join.
Alternativa A — ❌ Incorreta
A afirmação de que Vendas é muito maior que Clientes não é, por si só, um cenário favorável ao Nested Loops. Se a tabela externa for a maior (Vendas), o join faria 10.000 varreduras na menor, o que pode ser ineficiente. O que importa é quem é a driving table e quantas correspondências existem. A alternativa não especifica a seletividade.
Alternativa B — ❌ Incorreta
Quando a query retorna um grande conjunto de resultados (mais de 10% dos dados), o Nested Loops tende a ser ineficiente, pois gera muitas operações de E/S aleatórias. Nesses casos, o Hash Join ou Merge Join são mais adequados, pois processam os dados em lote.
Alternativa C — ✅ Correta ⟵ GABARITO
Nested Loops é ideal quando a tabela externa (aqui Clientes, com 1.000 linhas) é pequena e a tabela interna (Vendas) possui um índice na coluna de junção, permitindo encontrar rapidamente as poucas correspondências para cada cliente. Isso minimiza o número total de acessos ao disco e torna o join eficiente.
Alternativa D — ❌ Incorreta
Se não houver índices nas colunas de junção, o Nested Loops exigiria uma varredura completa da tabela Vendas para cada linha de Clientes, resultando em 1.000 × 10.000 = 10 milhões de comparações de linhas, o que é extremamente lento. O otimizador provavelmente escolheria outro método (como Hash Join com tabelas pequenas, ou Merge Join após ordenação).
Alternativa E — ❌ Incorreta
A necessidade de ordenação final não influencia diretamente a escolha do método de junção. A ordenação pode ser feita após o join, independentemente do método utilizado. O Nested Loops não oferece vantagens específicas para ordenação.