Quiz de Indexação de Banco de Dados

Quiz de Indexação de Banco de Dados

Teste seus conhecimentos sobre árvores B, estratégias de indexação e otimização de consultas.

1. 1. O que é um índice de banco de dados?

   • Uma cópia de backup de toda a tabela armazenada em um disco separado
   • Uma estrutura de dados separada que mapeia valores de colunas para as localizações dos registros, acelerando a recuperação de dados
   • Uma restrição (constraint) que garante a unicidade dos registros em uma tabela
   • Um log de transações que registra cada INSERT, UPDATE e DELETE

2. 2. Qual das seguintes alternativas melhor descreve o trade-off entre leitura e escrita ao adicionar um índice?

   • Índices aceleram leituras e escritas igualmente
   • Índices tornam as leituras mais lentas porque o planejador precisa verificar o índice primeiro
   • Índices aceleram as leituras, mas adicionam sobrecarga às operações de INSERT, UPDATE e DELETE
   • Índices afetam apenas o desempenho do DELETE, não do SELECT

3. 3. O que distingue um índice primário de um índice secundário?

   • Um índice primário é sempre um índice hash; índices secundários são sempre árvores B
   • Um índice primário é construído sobre a chave primária e normalmente determina a ordem física dos registros; índices secundários são criados sobre outras colunas
   • Um índice primário só pode ser definido na criação da tabela; índices secundários podem ser adicionados a qualquer momento
   • Não há diferença prática: os termos são intercambiáveis

4. 4. O que é uma varredura completa da tabela (full table scan) e quando o banco de dados a utiliza?

   • A leitura sequencial de todos os registros da tabela; utilizada quando não há índice adequado ou quando o planejador estima que seja mais barata que a busca por índice
   • A leitura apenas dos primeiros e últimos registros da tabela para estimar seu tamanho
   • Uma operação especial que reconstrói todos os índices da tabela
   • Uma varredura que lê apenas registros correspondentes a uma cláusula WHERE

5. 5. Dada a consulta `SELECT * FROM orders WHERE customer_id = 42`, qual condição permite ao banco de dados utilizar um índice em `customer_id`?

   • A tabela deve ter menos de 1.000 linhas
   • Deve existir um índice na coluna `customer_id`
   • `customer_id` deve ser a primeira coluna definida na tabela
   • A consulta precisa usar `LIMIT 1`

6. 6. O que um índice UNIQUE garante?

   • Que a coluna indexada nunca contenha NULL
   • Que nenhum par de registros compartilhe o mesmo valor na(s) coluna(s) indexada(s)
   • Que o índice seja armazenado em uma tablespace separada dos dados da tabela
   • Que consultas SELECT nessa coluna sempre retornem resultados ordenados

7. 7. No PostgreSQL, o que o comando `EXPLAIN` exibe?

   • A versão no padrão SQL da sua consulta após a reescrita automática
   • O plano de execução que o planejador pretende usar, incluindo tipos de nós, custos estimados e contagens de linhas
   • Uma lista de todos os índices nas tabelas referenciadas na consulta
   • O tempo real de relógio que a consulta levou para ser executada

8. 8. Qual é a principal diferença entre um índice clusterizado (clustered) e um não clusterizado (non-clustered)?

   • O índice clusterizado armazena os dados reais das linhas na ordem do índice; o índice não clusterizado armazena apenas ponteiros para as linhas de dados
   • O índice clusterizado só pode ser criado em uma única coluna; índices não clusterizados suportam múltiplas colunas
   • Índices não clusterizados são mais rápidos para todos os tipos de consulta
   • Índices clusterizados exigem mais espaço em disco do que índices não clusterizados

9. 9. Por que índices em colunas de baixa cardinalidade (como um booleano `is_active`) costumam ser ineficazes?

   • O banco de dados não consegue construir índices em árvore B em colunas booleanas
   • Quando uma coluna possui pouquíssimos valores distintos, a busca por índice pode acessar grande parte da tabela, tornando a varredura sequencial mais barata
   • Índices de baixa cardinalidade são descartados automaticamente pelo mecanismo do banco de dados
   • Índices em booleanos exigem um mecanismo de armazenamento especial não disponível no PostgreSQL padrão

10. 10. O que acontece com um índice quando você atualiza a coluna indexada de um registro?

    • Nada: os índices são atualizados apenas durante o próximo comando VACUUM
    • A entrada antiga no índice é removida e uma nova entrada é inserida para refletir o valor atualizado
    • O índice inteiro é reconstruído do zero após cada UPDATE
    • A entrada do índice é marcada como inválida até a execução do próximo SELECT

11. 11. Ao percorrer um índice em árvore B para localizar o valor de uma chave, qual é a complexidade de tempo da busca?

    • O(n): linear em relação ao número de registros
    • O(log n): logarítmica em relação ao número de registros
    • O(1): tempo constante independentemente do tamanho da tabela
    • O(n²): quadrática em relação ao número de registros

12. 12. Qual afirmação compara corretamente um índice hash e um índice em árvore B?

    • Índices hash suportam consultas por intervalo (>, <, BETWEEN); árvores B não
    • Índices hash oferecem buscas por igualdade em O(1), mas não suportam consultas por intervalo nem ORDER BY; árvores B suportam todos eles
    • Índices hash armazenam dados de forma ordenada, tornando varreduras por faixa muito rápidas
    • Índices hash e árvores B possuem características idênticas de desempenho; a escolha é meramente estética

13. 13. Dado um índice composto em `(last_name, first_name)`, qual cláusula WHERE pode utilizar o índice de forma eficiente?

    • `WHERE first_name = 'Alice'` (ignorando `last_name`)
    • `WHERE last_name = 'Smith'`
    • `WHERE first_name = 'Alice' AND last_name = 'Smith'`: apenas quando ambas as colunas aparecem
    • Nenhuma das colunas pode usar o índice a menos que a consulta inclua todas as colunas indexadas

14. 14. O que é um índice de cobertura (covering index)?

    • Um índice que abrange todas as colunas da tabela
    • Um índice que contém todas as colunas necessárias para responder a uma consulta, permitindo que o mecanismo retorne resultados apenas pelo índice, sem acessar a heap da tabela
    • Um índice que se expande automaticamente para cobrir novas colunas conforme são adicionadas à tabela
    • Um índice que cobre valores NULL que índices comuns normalmente ignorariam

15. 15. O que é seletividade de índice e por que ela é importante para o planejador de consultas?

    • O número de páginas que o índice ocupa no disco; mais páginas significam varreduras mais velozes
    • A razão entre valores distintos e o total de registros; alta seletividade significa poucas linhas por valor de chave, tornando o índice mais eficiente para buscas
    • Indica se o índice foi criado ou não na coluna de chave primária
    • A porcentagem de consultas na carga de trabalho que referenciam a coluna indexada

16. 16. O que é um índice parcial no PostgreSQL?

    • Um índice construído apenas sobre os primeiros N bytes de uma coluna de texto
    • Um índice que inclui apenas os registros que atendem a um predicado WHERE, reduzindo seu tamanho e custo de manutenção
    • Um índice que cobre apenas a metade de uma chave composta
    • Um índice criado automaticamente pelo planejador para a execução de uma única consulta

17. 17. O que é um índice baseado em função (índice de expressão)?

    • Um índice armazenado como uma procedure que se reconstrói todas as noites
    • Um índice construído sobre o resultado de uma expressão ou função aplicada a uma ou mais colunas, permitindo buscas indexadas em predicados calculados
    • Um índice que dispara uma função definida pelo usuário sempre que uma linha é inserida
    • Um índice cujos valores de chave são criptografados com uma função hash para segurança

18. 18. O que é inchaço de índice (index bloat) e como o comando VACUUM ajuda no PostgreSQL?

    • O inchaço ocorre quando o índice possui colunas em excesso; o VACUUM remove as colunas adicionais automaticamente
    • O inchaço é o acúmulo de referências a tuplas mortas nas páginas do índice resultantes de UPDATEs e DELETEs; o VACUUM recupera essas páginas e as marca como reutilizáveis
    • O inchaço significa que o arquivo de índice ultrapassou o tamanho da tabela; o VACUUM compacta ambos para o mesmo tamanho
    • O inchaço decorre de leituras concorrentes excessivas; o VACUUM reinicia os contadores de leitura

19. 19. Por que o planejador de consultas do PostgreSQL pode ignorar um índice mesmo quando ele existe na coluna filtrada?

    • O PostgreSQL nunca ignora um índice depois de criado: ele é sempre utilizado
    • O modelo de custo do planejador estima que uma varredura sequencial é mais barata, frequentemente porque o filtro corresponde a uma grande parcela dos registros ou as estatísticas estão desatualizadas
    • O índice só pode ser utilizado se a consulta contiver uma cláusula ORDER BY na coluna indexada
    • Índices são utilizados apenas para operações de JOIN, nunca para filtragem com cláusula WHERE

20. 20. Dado um índice em árvore B em uma coluna `name`, qual padrão de busca com LIKE pode utilizar o índice?

    • `WHERE name LIKE '%smith'` (curinga no início / sufixo)
    • `WHERE name LIKE '%smith%'` (curingas em ambos os lados)
    • `WHERE name LIKE 'smith%'` (curinga no final / prefixo)
    • Nenhum: o operador LIKE nunca utiliza índices em árvore B

21. 21. Qual tipo de índice do PostgreSQL é projetado para tipos de dados geométricos e espaciais, como pontos, caixas (boxes) e polígonos?

    • GIN (Generalized Inverted Index)
    • BRIN (Block Range INdex)
    • GiST (Generalized Search Tree)
    • SPGIST (Space-Partitioned GiST)

22. 22. Um índice GIN (Generalized Inverted Index) é mais adequado para qual tipo de coluna?

    • Uma chave primária inteira de valor único
    • Uma coluna contendo valores compostos, como arrays, JSONB ou documentos de busca textual `tsvector`
    • Uma coluna de timestamp monotonicamente crescente em uma tabela append-only
    • Uma coluna booleana de baixa cardinalidade

23. 23. O que é um índice BRIN e para qual característica de tabela ele é mais indicado?

    • Um índice de intervalo de blocos que armazena valores mínimos/máximos por intervalo de páginas; ideal para tabelas grandes com colunas correlacionadas à ordem física, como `created_at` em tabelas append-only
    • Um índice de intervalo balanceado que substitui árvores B em todas as colunas numéricas
    • Um índice de intervalo por bitmap usado para acelerar varreduras bitmap na heap em dados aleatórios
    • Um índice de intervalo binário que funciona apenas com chaves primárias UUID

24. 24. O que é 'amplificação de escrita' (write amplification) no contexto de índices LSM-tree (Log-Structured Merge-tree)?

    • Cada escrita lógica é gravada fisicamente múltiplas vezes através dos diferentes níveis da LSM-tree durante os processos de compactação
    • O banco de dados grava uma cópia redundante de cada linha no log de transações
    • A amplificação de escrita refere-se à sobrecarga de atualizar nós pais de uma árvore B após a divisão de uma folha (leaf split)
    • É a latência adicional gerada pela persistência do log de escrita prévia (write-ahead log) no disco

25. 25. Qual é a finalidade do comando `CREATE INDEX CONCURRENTLY` no PostgreSQL?

    • Ele constrói o índice em múltiplos núcleos de CPU simultaneamente para acelerar a criação
    • Ele constrói o índice sem adquirir um bloqueio exclusivo na tabela, permitindo leituras e escritas concorrentes durante a criação ao custo de um tempo de construção maior
    • Ele cria o índice em uma réplica antes de promovê-la a primária, evitando tempo de inatividade
    • Ele posterga a aplicação do índice até após o COMMIT, melhorando a taxa de transações

26. 26. O que é um 'índice invisível' (suportado no MySQL 8+ e Oracle) e qual é seu principal caso de uso?

    • Um índice criptografado em repouso para que seu conteúdo não seja lido por usuários não autorizados
    • Um índice que continua sendo atualizado pelo mecanismo, mas fica oculto para o planejador de consultas, usado para testar com segurança o impacto de remover um índice antes do DROP definitivo
    • Um índice armazenado exclusivamente na memória, nunca gravado em disco
    • Um índice em tabelas do catálogo do sistema que não é exibido nas views do information_schema

27. 27. De que maneira o modelo MVCC (Multi-Version Concurrency Control) do PostgreSQL contribui para o inchaço de índices (index bloat) ao longo do tempo?

    • O MVCC compacta versões antigas de linhas, fragmentando os índices ao longo do tempo
    • Cada UPDATE cria uma nova versão da tupla na heap mantendo a versão anterior; as entradas antigas e novas coexistem no índice até que o VACUUM colete as tuplas mortas
    • O MVCC força o índice a armazenar o identificador de transação ao lado de cada chave, dobrando seu tamanho
    • O MVCC não tem efeito em índices: apenas páginas da heap acumulam tuplas mortas

28. 28. Quando o planejador do PostgreSQL opta por um Bitmap Index Scan em vez de um Index Scan convencional?

    • Quando a consulta retorna exatamente um único registro
    • Quando múltiplos índices precisam ser combinados (AND/OR) ou quando a contagem estimada de linhas é moderada, permitindo ler as páginas da heap em ordem física em vez de fazer buscas aleatórias repetidas
    • Quando a tabela não possui páginas de heap: os dados ficam no próprio índice
    • O Bitmap Index Scan é sempre mais rápido e preferido em relação ao Index Scan comum

29. 29. Em uma tabela particionada, qual é a consideração fundamental ao criar índices para assegurar que todas as partições sejam beneficiadas?

    • Índices devem ser criados apenas na coluna da chave de partição; outras colunas não podem ser indexadas
    • Criar um índice na tabela particionada pai no PostgreSQL 11+ propaga o índice automaticamente para todas as partições existentes e futuras
    • Cada partição exige um índice criado manualmente com nome exclusivo; não existe propagação automática
    • Tabelas particionadas não suportam índices em árvore B; apenas índices BRIN estão disponíveis

30. 30. Qual view de sistema do PostgreSQL você consultaria para descobrir o número de varreduras por índice, varreduras sequenciais e tuplas recuperadas para índices criados por usuários?

    • `pg_indexes`
    • `information_schema.table_constraints`
    • `pg_stat_user_indexes`
    • `pg_index`