Banco de Dados · CESPE / CEBRASPE · 2024 | Questão sqc-ce403657

GabaritoC — a criação de índices em colunas frequentemente usadas em cláusulas WHERE ou em junções (JOIN) nas consultas.

Otimização de Consultas em Banco de Dados Relacional

Gabarito: letra C. A prática mais eficaz para melhorar o desempenho de consultas em tabelas grandes é a criação de índices em colunas frequentemente usadas em cláusulas WHERE ou em junções (JOIN), pois os índices são estruturas auxiliares que agilizam a recuperação de registros, evitando varreduras completas na tabela. As demais alternativas apresentam práticas que não são eficazes ou até prejudiciais ao desempenho.

A otimização de consultas, também chamada de tuning, é o processo pelo qual o SGBD escolhe uma estratégia de execução (plano de consulta) para recuperar os resultados de forma eficiente. O objetivo é minimizar o tempo de resposta e obter ganho de desempenho. Para isso, o SGBD avalia sistematicamente estratégias alternativas, utilizando regras heurísticas e estimativas de custo. Os índices são um dos principais recursos físicos que o otimizador pode utilizar para acelerar o acesso aos dados.

Um índice é uma estrutura de dados auxiliar associada a uma tabela, que organiza os valores de uma ou mais colunas (chamadas de chave do índice) de forma a permitir buscas rápidas. Quando uma consulta filtra registros por uma coluna indexada (ex.: WHERE coluna = valor) ou realiza junções entre tabelas usando colunas indexadas, o SGBD pode usar o índice para localizar diretamente as linhas relevantes, em vez de percorrer toda a tabela (full table scan). Isso reduz drasticamente o número de operações de I/O e o tempo de execução, especialmente em tabelas grandes.

A criação de índices, porém, não é gratuita: cada índice ocupa espaço em disco e precisa ser atualizado a cada operação de INSERT, UPDATE ou DELETE, o que pode degradar o desempenho de escritas. Por isso, a prática recomendada é criar índices seletivamente, apenas nas colunas que são realmente usadas com frequência em filtros e junções, e evitar índices em colunas com baixa seletividade (poucos valores distintos) ou em tabelas com muitas operações de escrita.

As demais alternativas apresentam práticas que não são eficazes ou até prejudiciais ao desempenho:

A) Manter a maior quantidade possível de dados em uma única tabela para reduzir junções é uma prática que vai contra os princípios de modelagem relacional e normalização. Isso aumenta a redundância, causa anomalias de inserção, exclusão e atualização, e pode até piorar o desempenho, pois tabelas maiores exigem mais I/O para varreduras.
B) Utilizar chaves primárias compostas em todas as tabelas não é uma prática recomendada para desempenho. Chaves compostas podem ser úteis em alguns casos, mas não garantem melhoria de desempenho e podem até prejudicar, pois índices maiores ocupam mais espaço e são mais lentos para atualizar.
D) Aumentar o tamanho das transações para incluir o máximo de operações possível é uma prática que pode piorar o desempenho e a concorrência. Transações longas aumentam a probabilidade de conflitos de bloqueio, reduzem a concorrência e podem causar problemas de recuperação em caso de falhas.

Portanto, a alternativa C é a única que apresenta uma prática comprovadamente eficaz para melhorar o desempenho de consultas em tabelas grandes.

Critério	A) Tabela única	B) Chave primária composta	C) Índices em colunas de WHERE/JOIN	D) Transações longas
Efeito no desempenho de consultas	Piora (mais I/O, redundância)	Neutro ou prejudicial (índices maiores)	Melhora significativamente (evita full table scan)	Piora (conflitos de bloqueio, menor concorrência)
Impacto em operações de escrita	Aumenta anomalias e custo de manutenção	Aumenta custo de atualização dos índices	Custo adicional de manutenção do índice	Aumenta risco de deadlocks e falhas
Alinhamento com boas práticas	Contraria normalização	Não é critério de otimização	Prática recomendada de tuning	Contraria recomendação de transações curtas

Alternativa A — ❌ Incorreta

Manter a maior quantidade possível de dados em uma única tabela para reduzir junções é uma prática que contraria os princípios de modelagem relacional e normalização. Isso aumenta a redundância, causa anomalias de inserção, exclusão e atualização, e pode até piorar o desempenho, pois tabelas maiores exigem mais I/O para varreduras. A normalização, ao contrário, busca minimizar redundância e anomalias, dividindo dados em tabelas menores e relacionadas.

Alternativa B — ❌ Incorreta

Utilizar chaves primárias compostas em todas as tabelas não é uma prática recomendada para desempenho. Chaves compostas podem ser úteis em alguns casos, mas não garantem melhoria de desempenho e podem até prejudicar, pois índices maiores ocupam mais espaço e são mais lentos para atualizar. A chave primária serve para garantir a unicidade dos registros, não para otimizar consultas.

Alternativa C — ✅ Correta ⟵ GABARITO

A criação de índices em colunas frequentemente usadas em cláusulas WHERE ou em junções (JOIN) é a prática mais eficaz para melhorar o desempenho de consultas em tabelas grandes. Os índices são estruturas auxiliares que agilizam a recuperação de registros, permitindo que o SGBD localize diretamente as linhas relevantes sem varrer a tabela inteira. Isso reduz o I/O e o tempo de resposta, especialmente em tabelas grandes.

Alternativa D — ❌ Incorreta

Aumentar o tamanho das transações para incluir o máximo de operações possível é uma prática que pode piorar o desempenho e a concorrência. Transações longas aumentam a probabilidade de conflitos de bloqueio, reduzem a concorrência e podem causar problemas de recuperação em caso de falhas. O ideal é manter transações curtas e eficientes.

Gabarito: letra C