Bancos de Dados: índices, transações, concorrência e desempenho para o Escriturário do Banco do Brasil – Agente de Tecnologia

Índices: por que existem e quando ajudam (ou atrapalham)

Índice é uma estrutura auxiliar que acelera a localização de linhas em uma tabela, reduzindo leituras desnecessárias. Em vez de varrer a tabela inteira (full scan), o SGBD navega pelo índice para encontrar rapidamente as chaves e, então, acessar as linhas correspondentes.

B-tree (noções) e impacto no desempenho

O índice mais comum em SGBDs relacionais é baseado em B-tree (ou variações como B+tree). A ideia central é manter as chaves ordenadas em uma árvore balanceada, permitindo buscas, inserções e remoções com custo logarítmico. Em termos práticos, isso significa poucas leituras de páginas (blocos) para chegar ao registro desejado.

• Busca por igualdade (ex.: WHERE conta_id = 123): tende a ser muito eficiente com B-tree.
• Busca por intervalo (ex.: WHERE data BETWEEN ...): B-tree também é adequada, pois mantém ordenação.
• Ordenação (ex.: ORDER BY data): pode ser acelerada se o índice estiver alinhado com a ordenação e filtros.
• Escritas (INSERT/UPDATE/DELETE): ficam mais caras, porque o SGBD precisa manter o índice atualizado. Quanto mais índices, maior o custo de escrita.

Quando um índice pode piorar

• Baixa seletividade: se o filtro retorna grande parte da tabela (ex.: coluna “status” com poucos valores), o SGBD pode preferir full scan.
• Tabela pequena: o overhead de usar índice pode superar o ganho.
• Muitos índices em tabela de alta escrita: aumenta latência e contenção em cenários concorrentes.

Exemplo prático: índice em conta e data

Em um sistema bancário, consultas típicas incluem extrato por conta e período. Um índice composto pode ajudar:

-- Exemplo conceitual (SQL ilustrativo): índice para extrato por conta e data (ordem importa!)(conta_id, data_movimento)

Esse índice tende a acelerar: filtrar por conta_id e, dentro da conta, varrer apenas o intervalo de datas.

Planos de execução (nível conceitual): como o SGBD decide

O plano de execução é a estratégia escolhida pelo otimizador para executar uma consulta. Mesmo sem entrar em comandos específicos de cada SGBD, é essencial entender os componentes conceituais mais cobrados em prova.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Operações comuns em planos

• Table/Full Scan: lê a tabela inteira (ou grande parte).
• Index Seek/Range Scan: navega no índice para achar chaves específicas ou intervalos.
• Lookup/Row Fetch: após achar a chave no índice, busca a linha na tabela (pode ser caro se houver muitos lookups).
• Join: combina tabelas. Pode ser Nested Loop, Hash Join ou Merge Join (conceitualmente).
• Sort/Aggregate: ordenação e agregações podem consumir CPU/memória e gerar I/O temporário.

Como raciocinar em questões

Em provas, costuma-se pedir a melhor justificativa para um plano usar (ou não) índice. Use este checklist:

• Seletividade: quantas linhas o filtro retorna?
• Colunas no predicado: o filtro usa a coluna indexada (e na ordem correta em índice composto)?
• Cobertura: o índice “cobre” a consulta (todas as colunas necessárias estão no índice), reduzindo lookups?
• Estatísticas: se estiverem desatualizadas, o otimizador pode escolher mal.
• Concorrência: em alta concorrência, certas estratégias reduzem bloqueios e tempo de retenção.

Miniestudo: índice cobrindo consulta

Considere uma consulta que precisa apenas de conta_id, data_movimento e valor. Se o índice incluir essas colunas, o SGBD pode evitar buscar a linha completa na tabela, reduzindo I/O e tempo de bloqueio.

Transações e propriedades ACID (com foco em cenários bancários)

Transação é uma unidade lógica de trabalho que deve ser executada de forma confiável. Em operações bancárias, transações garantem que saldos e lançamentos permaneçam consistentes mesmo com falhas e concorrência.

ACID

• Atomicidade: ou tudo acontece, ou nada acontece. Ex.: débito e crédito em uma transferência devem ocorrer juntos.
• Consistência: regras do banco de dados (constraints, integridade, regras de negócio persistidas) não podem ser violadas ao final da transação.
• Isolamento: transações simultâneas não devem interferir de forma indevida, evitando anomalias.
• Durabilidade: após commit, os dados persistem mesmo após falhas (via logs, flush controlado, etc.).

Estudo de caso 1: transferência entre contas (passo a passo)

Cenário: transferir R$ 100 da Conta A para a Conta B. Objetivo: manter saldo e lançamentos consistentes sob alta concorrência.

Passo a passo conceitual:

• 1) Iniciar transação: o SGBD passa a controlar isolamento e logging.
• 2) Ler saldos necessários: obter saldo da Conta A (e eventualmente da Conta B) com o nível de isolamento definido.
• 3) Validar regra: saldo da Conta A deve ser suficiente.
• 4) Atualizar saldo da Conta A: debitar 100.
• 5) Atualizar saldo da Conta B: creditar 100.
• 6) Inserir lançamentos: registrar movimentações (débito/crédito) em tabela de movimentos.
• 7) Commit: tornar alterações visíveis e duráveis.
• 8) Em caso de falha: rollback desfaz tudo (atomicidade).

Ponto de prova: se o sistema debita a Conta A e falha antes de creditar a Conta B, sem transação adequada, ocorre inconsistência. Com transação ACID, o rollback evita “dinheiro sumindo”.

Concorrência: bloqueios, níveis de isolamento e anomalias

Em bancos, é comum haver múltiplas transações simultâneas: pagamentos, transferências, consultas de extrato, atualizações de limites, rotinas de conciliação. O SGBD precisa equilibrar consistência e desempenho.

Bloqueios (locks): ideia central

Bloqueios controlam acesso concorrente a dados. Conceitualmente:

• Lock compartilhado (S): permite leitura por várias transações, mas impede escrita concorrente no mesmo item.
• Lock exclusivo (X): necessário para escrita; impede outras leituras/escritas conflitantes.

Quanto maior o tempo de retenção do lock, maior a chance de contenção (esperas), impactando desempenho em pico.

Níveis de isolamento e anomalias clássicas

Os níveis de isolamento definem quais fenômenos são permitidos. As anomalias mais cobradas:

• Leitura suja (dirty read): uma transação lê dado ainda não confirmado por outra. Se a outra der rollback, a primeira leu algo que “nunca existiu”.
• Leitura não repetível (non-repeatable read): a mesma linha lida duas vezes na mesma transação retorna valores diferentes porque outra transação confirmou uma atualização no meio.
• Phantom read: ao repetir uma consulta por predicado (ex.: “todas as transações do dia”), surgem novas linhas porque outra transação inseriu e confirmou linhas que satisfazem o predicado.

Mapeamento conceitual típico (pode variar por implementação, mas é o raciocínio de prova):

• Read Uncommitted: pode permitir leitura suja, não repetível e phantom.
• Read Committed: evita leitura suja; ainda pode ter não repetível e phantom.
• Repeatable Read: evita leitura suja e não repetível; phantom pode ocorrer dependendo do mecanismo.
• Serializable: evita as três; maior custo e maior chance de bloqueios/esperas.

Exercícios de identificação de anomalias (raciocínio)

Exercício 1 (leitura suja): T1 atualiza saldo da Conta A de 500 para 0, mas ainda não confirma. T2 lê saldo 0 e decide negar uma compra. Em seguida, T1 dá rollback e o saldo volta a 500. Qual anomalia ocorreu?

Resposta esperada: leitura suja (T2 leu dado não confirmado).

Exercício 2 (não repetível): T1 lê saldo da Conta A = 500. T2 debita 100 e confirma. T1 lê novamente o saldo da Conta A e agora vê 400. Qual anomalia?

Resposta esperada: leitura não repetível (mesma linha, valores diferentes na mesma transação).

Exercício 3 (phantom): T1 consulta “quantas transferências acima de R$ 1.000 ocorreram hoje” e obtém 10. T2 insere uma nova transferência de R$ 2.000 e confirma. T1 repete a consulta e obtém 11. Qual anomalia?

Resposta esperada: phantom (novas linhas passaram a satisfazer o predicado).

Deadlocks: como surgem e como lidar

Deadlock ocorre quando duas (ou mais) transações ficam esperando indefinidamente por recursos bloqueados uma pela outra, formando um ciclo de espera.

Exemplo típico em transferência (ordem de locks)

T1: transfere de A para B. T2: transfere de B para A ao mesmo tempo.

• T1 obtém lock exclusivo na Conta A e tenta lock na Conta B.
• T2 obtém lock exclusivo na Conta B e tenta lock na Conta A.
• Ambas esperam: deadlock.

Mitigações cobradas em prova

• Ordenação consistente de acesso: sempre bloquear contas na mesma ordem (ex.: menor conta_id primeiro). Reduz ciclos.
• Transações curtas: menos tempo segurando locks, menor chance de deadlock.
• Retry: SGBDs detectam deadlock e abortam uma transação; a aplicação deve estar preparada para reexecutar.
• Índices adequados: evitam varreduras longas que seguram locks por mais tempo.

Alta concorrência em bancos: consistência com desempenho

Em horários de pico, há muitas transações simultâneas atualizando saldos, registrando lançamentos e consultando extratos. O SGBD mantém consistência combinando isolamento, locks (ou mecanismos equivalentes) e logs de transação.

Cenário: múltiplas compras debitando a mesma conta

Se duas transações tentarem debitar simultaneamente a Conta A, o isolamento deve impedir “perda de atualização” (uma sobrescrever a outra). Conceitualmente, o SGBD garante que as atualizações sejam serializadas de forma segura (por locks exclusivos na linha/página ou por controle multiversão, dependendo do SGBD).

Questão de raciocínio: qual o risco de isolamento baixo?

Se o sistema usa isolamento muito permissivo, pode ocorrer leitura de saldo desatualizado e aprovar operações indevidas. Se usa isolamento muito alto em tudo, pode aumentar contenção e tempo de resposta. Em prova, a resposta costuma buscar o equilíbrio: operações críticas (movimentação financeira) exigem isolamento mais forte; relatórios e consultas podem tolerar menor isolamento, desde que não violem requisitos.

Estudo de caso 2: processamento em lote (batch) e impacto em locks e índices

Processamentos em lote são comuns: fechamento diário, conciliação, cálculo de tarifas, atualização de limites, geração de relatórios regulatórios. Eles podem competir com transações online.

Risco: lote causando contenção

Um lote que atualiza muitas linhas pode:

• Segurar locks por muito tempo, bloqueando operações online.
• Gerar grande volume de log, aumentando I/O.
• Degradar cache/buffer por varreduras extensas.

Passo a passo prático: reduzir impacto de um lote

• 1) Fatiar em lotes menores: processar por janelas (ex.: por agência, por faixa de contas, por período), confirmando a cada bloco.
• 2) Usar índices alinhados ao critério de seleção: se o lote filtra por data e status, índices nessas colunas reduzem varredura e tempo de lock.
• 3) Evitar atualizações desnecessárias: atualizar apenas quando houver mudança real (reduz escrita e log).
• 4) Planejar janelas e prioridades: executar em horários de menor pico quando possível.
• 5) Monitorar plano conceitual: se o lote faz full scan e atualiza milhões de linhas, a contenção tende a aumentar; com acesso mais seletivo, diminui.

Desempenho: relação entre índices, concorrência e tempo de transação

Em sistemas transacionais, desempenho não é só “consulta rápida”; é também reduzir tempo de retenção de locks e evitar esperas. Alguns pontos de prova:

• Índice acelera leitura, mas pode aumentar custo de escrita: em tabelas de lançamentos com alta inserção, índices demais podem reduzir throughput.
• Transação longa é inimiga da concorrência: quanto mais tempo até o commit, mais tempo segurando recursos.
• Consultas pouco seletivas tendem a ler muito e potencialmente bloquear mais (dependendo do isolamento e do mecanismo).
• Escolha de índice composto: a ordem das colunas importa; deve refletir filtros mais seletivos e padrões de consulta.

Exercício: identificar o gargalo provável

Um sistema de extrato está lento em pico. A consulta filtra por conta_id e intervalo de datas, mas existe apenas índice em data_movimento. Qual hipótese mais provável?

• A consulta pode estar varrendo muitas linhas por data e depois filtrando por conta, causando I/O alto.
• Um índice composto (conta_id, data_movimento) tende a ser mais adequado ao padrão.

Checklist de prova: o que observar em enunciados

• Se o enunciado fala em “muitas transações simultâneas”, pense em isolamento, locks, contenção e deadlocks.
• Se fala em “consulta lenta apesar de índice”, pense em baixa seletividade, ordem de colunas em índice composto, lookups excessivos, estatísticas.
• Se fala em “inconsistência após falha”, pense em atomicidade e durabilidade (log/commit/rollback).
• Se descreve leituras diferentes na mesma transação, classifique: dirty, non-repeatable, phantom.