Banco de Dados · VUNESP · 2023 | Questão sqc-vu195585

GabaritoA — criar índices em uma ou mais colunas consultadas no(s) comando(s) SQL.

Otimização de consultas SQL: o papel dos índices

Gabarito: letra A. A forma clássica e mais direta de otimizar consultas SQL é criar índices em colunas consultadas, pois isso permite ao SGBD localizar os registros sem varrer a tabela inteira (evitando o full table scan). As demais alternativas propõem medidas que não são técnicas de otimização de consultas — eliminar nulos, limitar colunas, usar nuvem ou restringir tabelas não aceleram a execução de um comando SQL específico.

A otimização de consultas é um dos pilares do desempenho de um banco de dados. Quando você executa um SELECT, o SGBD precisa encontrar os dados solicitados. Sem um índice, ele é obrigado a percorrer todas as linhas da tabela para verificar quais atendem à condição do WHERE — isso é a varredura completa, ou full table scan, que fica cada vez mais lenta conforme a tabela cresce. O índice funciona como um catálogo ou sumário: ele organiza os valores de uma ou mais colunas em uma estrutura de busca rápida (tipicamente uma árvore B, ou B-tree), permitindo que o SGBD salte diretamente para os registros relevantes, em vez de ler tudo.

Imagine uma tabela Clientes com 10 milhões de linhas e uma consulta SELECT * FROM Clientes WHERE CPF = '123.456.789-00'. Sem índice na coluna CPF, o banco lê as 10 milhões de linhas para achar a que interessa. Com um índice em CPF, ele navega pela árvore e encontra o registro em pouquíssimas operações — uma diferença de ordens de magnitude no tempo de resposta. Por isso, a criação de índices é a técnica mais citada e mais fundamental de otimização de consultas SQL.

É importante distinguir o que é otimização de consulta do que é outra forma de melhoria de desempenho. O contexto de bancos como o Oracle mostra que a otimização se apoia em quatro áreas: melhoria nas consultas SQL e uso adequado de índices, gerenciamento eficiente de memória e processamento, controle de operações de I/O e armazenamento, e monitoramento contínuo. Os índices atacam diretamente a primeira área — a da consulta em si. As outras alternativas da questão, ou tratam de aspectos estruturais que não têm relação direta com a velocidade de uma consulta específica, ou são medidas drásticas e sem fundamento técnico.

A pegadinha desta questão é justamente atrair o candidato para soluções genéricas de "banco de dados" (nuvem, eliminar nulos, limitar estruturas) quando o enunciado pede especificamente uma forma de otimizar consultas SQL. A banca testa se você sabe que o índice é a ferramenta certa para acelerar a leitura de dados, e não apenas se conhece conceitos gerais de administração de banco.

Guarde o critério: otimização de consulta = reduzir o custo de execução de um comando SQL. Índice faz exatamente isso. As outras opções não têm esse efeito direto e mensurável sobre a execução de uma consulta.

Critério	A) Criar índices	B) Eliminar nulos	C) Limitar colunas a 8	D) Banco em nuvem	E) Restringir nº de tabelas
Efeito direto na velocidade de um SELECT específico	✅ Sim — evita full table scan	❌ Não	❌ Não	❌ Não	❌ Não
Técnica reconhecida de otimização de consultas	✅ Sim — padrão em SGBDs	❌ Não	❌ Não	❌ Não	❌ Não
Impacto na estrutura lógica dos dados	Nenhum — apenas adiciona estrutura auxiliar	❌ Altera dados (remove informação legítima)	❌ Altera modelagem (arbitrário)	Nenhum — apenas infraestrutura	❌ Altera modelagem
Custo de implementação	Baixo e reversível (CREATE INDEX)	Alto e destrutivo	Alto e sem ganho real	Alto (financeiro)	Alto e sem ganho real

Alternativa A — ✅ Correta ⟵ GABARITO

Criar índices em colunas consultadas é a técnica canônica de otimização de consultas SQL. O índice evita a varredura completa da tabela, permitindo acesso direto aos registros que satisfazem a condição. É a resposta que a banca espera, pois ataca diretamente o custo de leitura dos dados.

Alternativa B — ❌ Incorreta

Eliminar todos os valores nulos de todas as tabelas não é uma técnica de otimização de consultas. Valores nulos representam ausência de informação e são legítimos em um banco relacional; removê-los seria uma intervenção drástica nos dados, sem relação com a velocidade de execução de um SELECT. Além disso, em muitos casos, a presença de nulos é semanticamente necessária (ex.: uma coluna data_devolucao em um empréstimo ainda não devolvido).

Alternativa C — ❌ Incorreta

Limitar a 8 o número de colunas por tabela é um número arbitrário e sem fundamento técnico. Não existe essa restrição nos SGBDs modernos, e o número de colunas não é, por si só, um fator determinante de desempenho de consultas. A otimização não passa por reduzir a estrutura da tabela, mas por melhorar o acesso aos dados.

Alternativa D — ❌ Incorreta

Manter o banco em nuvem é uma decisão de infraestrutura e hospedagem, não uma técnica de otimização de consultas SQL. A nuvem pode oferecer mais recursos de hardware, mas não altera a forma como uma consulta é executada pelo SGBD. A otimização de consulta é uma atividade lógica, independente de onde o banco está fisicamente hospedado.

Alternativa E — ❌ Incorreta

Restringir o número total de tabelas do banco não otimiza consultas. O número de tabelas é uma decisão de modelagem de dados, e não há um limite ideal que acelere consultas. Pelo contrário, uma modelagem adequada pode até envolver mais tabelas (normalização), e o desempenho é obtido com índices, não com a redução da quantidade de tabelas.

PEGA ESSA DICA!

Quando a questão falar em "otimizar consultas SQL", pense imediatamente em índices. Eles são a ferramenta padrão para acelerar SELECT, UPDATE e DELETE com WHERE. As outras opções (nuvem, eliminar nulos, limitar estruturas) são distratores que apelam para noções vagas de "melhoria" sem relação com a execução de um comando SQL.

Gabarito: letra A