Questão de Banco de Dados — SGBD - Sistema de Gerenciamento de Banco de Dados — Quadrix 2025

Otimização de consultas SQL com índices

Gabarito: letra C. Em um SGBD relacional, a criação de índices sobre as colunas mais utilizadas nas cláusulas WHERE e JOIN é a técnica clássica e adequada para acelerar consultas em tabelas com milhões de registros, pois permite ao otimizador localizar rapidamente as linhas relevantes sem varrer a tabela inteira (full scan). As demais alternativas propõem soluções que degradam a integridade, a estrutura ou o desempenho do banco.

Um índice em banco de dados relacional é uma estrutura auxiliar de dados (geralmente uma árvore B+ ou hash) que armazena, de forma ordenada, os valores de uma ou mais colunas, juntamente com ponteiros para as linhas correspondentes na tabela. Quando uma consulta filtra por uma coluna indexada (ex.: WHERE cliente_id = 123) ou faz uma junção (JOIN) usando uma coluna indexada, o SGBD pode usar o índice para encontrar as linhas em tempo logarítmico, em vez de percorrer todos os milhões de registros sequencialmente. Isso reduz drasticamente o número de operações de I/O e o tempo de resposta.

A decisão de quais colunas indexar deve considerar o padrão de consultas da aplicação: colunas usadas em filtros (WHERE), em junções (JOIN) e em ordenações (ORDER BY) são candidatas naturais. No entanto, índices não são gratuitos: cada índice ocupa espaço em disco e adiciona overhead em operações de INSERT, UPDATE e DELETE, pois precisa ser mantido atualizado. Por isso, a criação deve ser criteriosa, evitando índices em colunas com baixa seletividade (ex.: colunas com poucos valores distintos, como um campo booleano) ou em tabelas com poucas linhas.

A situação descrita no enunciado — tabela com milhões de registros e consultas frequentes por colunas específicas — é o cenário clássico em que a indexação se mostra a solução mais eficaz. O otimizador de consultas do SGBD, ao receber uma consulta que referencia uma coluna indexada, pode escolher entre usar o índice (acesso indexado) ou fazer uma varredura completa (full scan), com base em estatísticas sobre a distribuição dos dados. Com um índice bem projetado, o custo estimado do acesso indexado é muito menor, e o plano de execução resultante é significativamente mais rápido.

A pegadinha desta questão está em distinguir a solução correta (índices) das alternativas que parecem plausíveis, mas são tecnicamente incorretas ou até prejudiciais. Por exemplo, "converter a tabela para CSV" não é uma operação de banco de dados relacional e removeria todas as garantias de integridade e eficiência do SGBD. "Eliminar chaves estrangeiras" comprometeria a integridade referencial sem trazer ganho de desempenho relevante. "Recriar a tabela diariamente" é uma operação destrutiva e sem sentido para otimização. "Substituir consultas por procedimentos armazenados" não acelera as consultas em si, pois o gargalo está no acesso aos dados, não na forma como a consulta é enviada.

Guarde o critério decisivo: a otimização de consultas em tabelas grandes passa por reduzir a quantidade de dados que o SGBD precisa examinar, e o índice é o mecanismo que permite esse acesso seletivo. É exatamente essa a fronteira que separa a alternativa correta das demais.

Alternativa A — ❌ Incorreta

Recriar a tabela diariamente para reduzir o número de registros é uma medida absurda e destrutiva. Isso apagaria todos os dados existentes, exigiria recarga completa e não resolveria o problema de desempenho — na verdade, criaria um gargalo enorme de processamento diário. A redução do número de registros só seria adequada se houvesse uma política de retenção de dados (ex.: arquivamento de registros antigos), mas isso não é feito recriando a tabela, e sim com comandos de exclusão ou particionamento.

Alternativa B — ❌ Incorreta

Converter a tabela para o formato CSV é um equívoco conceitual. CSV é um formato de arquivo de texto simples, sem estrutura de banco de dados, sem índices, sem tipos de dados e sem suporte a consultas SQL eficientes. Um SGBD relacional não "converte" tabelas para CSV para acesso direto; isso removeria todas as funcionalidades do SGBD (integridade, concorrência, segurança) e tornaria as consultas ainda mais lentas, pois exigiria leitura e parsing de todo o arquivo a cada consulta.

Alternativa C — ✅ Correta ⟵ GABARITO

Criar índices sobre as colunas mais utilizadas nas cláusulas WHERE e JOIN é a ação adequada e consagrada para otimizar consultas em tabelas com milhões de registros. O índice permite ao SGBD localizar rapidamente as linhas que atendem ao filtro ou que participam da junção, evitando a varredura completa da tabela. Isso reduz drasticamente o tempo de resposta das consultas, que é exatamente o problema descrito no enunciado.

Alternativa D — ❌ Incorreta

Substituir todas as consultas por procedimentos armazenados, independentemente da lógica, não otimiza o desempenho. Procedimentos armazenados (stored procedures) são blocos de código SQL que ficam no servidor, mas a consulta SQL dentro deles ainda precisa ser executada pelo otimizador. Se a consulta não estiver bem indexada, o procedimento será tão lento quanto a consulta direta. Além disso, "independentemente da lógica" é um erro: procedimentos devem ser usados com critério, não como solução automática para lentidão.

Alternativa E — ❌ Incorreta

Eliminar todas as chaves estrangeiras para evitar travamentos por integridade referencial é uma medida prejudicial. As chaves estrangeiras garantem a integridade referencial dos dados, e sua remoção permitiria a inserção de dados órfãos, corrompendo a consistência do banco. Além disso, a lentidão descrita no enunciado não é causada por chaves estrangeiras, mas pela falta de índices adequados. A remoção de chaves estrangeiras não traria ganho de desempenho relevante e causaria danos graves à qualidade dos dados.

Gabarito: letra C