Métodos de Acesso em Banco de Dados
Gabarito: letra A – Índice Clusterizado. Em tabelas com milhões de registros onde a maioria das consultas filtra por um campo específico, o índice clusterizado é o mais adequado, pois reorganiza fisicamente os dados na ordem da chave do índice, tornando a recuperação por esse campo extremamente eficiente. As demais opções ou não otimizam consultas por campo específico ou são menos eficientes nesse cenário.
A banca testa o conhecimento sobre os diferentes métodos de acesso e suas aplicações práticas. Em tabelas de grande porte, a escolha do tipo de índice impacta diretamente o desempenho das consultas.
Método de Acesso | Descrição | Adequação para Tabela de Grande Porte com Consultas por Campo Específico | Observações |
|---|
Índice Clusterizado | Reorganiza fisicamente os dados na ordem da chave do índice. | Mais adequado. Torna a recuperação por esse campo extremamente eficiente, pois linhas com valores próximos ficam adjacentes no disco. | Ideal para chaves primárias; só pode haver um por tabela. |
Índice Não Clusterizado | Estrutura separada com chave e ponteiro para a linha. | Menos eficiente. Cada acesso pode exigir lookup extra na tabela, se o índice não cobrir a consulta. | Útil para consultas variadas, mas não otimiza tanto quanto o clusterizado para um campo único e frequente. |
Heap Table | Tabela sem índice, armazena registros sem ordem. | Inadequado. Consultas por campo específico exigem varredura completa (full scan), inviável em milhões de registros. | Pior método para o cenário descrito. |
Hash Table | Índice otimizado para consultas de igualdade exata. | Limitado. Eficiente apenas para buscas por valor único; não suporta consultas por faixa, ordenação ou like com coringa. | Índice clusterizado oferece desempenho similar ou superior, com maior versatilidade. |
Partitioning Table | Divide a tabela em partições menores com base em uma chave. | Não otimiza diretamente. Ajuda na manutenção e gerenciamento, mas não acelera consultas por campo específico sem um índice adequado. | Pode ser combinada com índices, mas sozinha não é a melhor escolha. |
Alternativa A – ✅ Correta ⟵ GABARITO
O índice clusterizado determina a ordem física de armazenamento das linhas da tabela de acordo com a chave do índice. Como só pode haver um por tabela, ele é ideal quando um campo é usado na maioria das consultas, pois as linhas com valores próximos ficam fisicamente adjacentes, reduzindo drasticamente o número de leituras de disco. É a escolha clássica para chaves primárias em tabelas grandes.
Alternativa B – ❌ Incorreta
O índice não clusterizado cria uma estrutura separada que contém a chave e um ponteiro para a linha correspondente. Embora acelere consultas por campo específico, cada acesso pode exigir uma operação extra de lookup na tabela (se o índice não cobrir a consulta), tornando-o menos eficiente que o clusterizado para o cenário descrito.
Alternativa C – ❌ Incorreta
Uma heap table (tabela sem índice) armazena registros sem qualquer ordem predefinida. Consultas por um campo específico exigem varredura completa (full scan) de todos os registros, o que é inviável em tabelas com milhões de linhas. É o pior método para o caso apresentado.
Alternativa D – ❌ Incorreta
O índice hash é otimizado para consultas de igualdade exata (busca por valor único), mas não suporta consultas por faixa, ordenação ou like com coringa no início. Embora possa ser eficiente para queries exatas, o índice clusterizado oferece desempenho similar ou superior para o campo específico, além de maior versatilidade.
Alternativa E – ❌ Incorreta
Partitioning table (tabela particionada) divide a tabela em partições menores baseadas em uma chave de partição, facilitando a manutenção e melhorando a performance em alguns cenários. No entanto, não é um método de acesso por si só; ainda é necessário criar índices dentro de cada partição para consultas específicas. Não substitui a necessidade de um índice clusterizado ou não clusterizado para consultas por campo.
Gabarito: letra A.