Transações, propriedades ACID, índices e otimização de consultas

Do zero

Pense numa transferência bancária de R$ 100 da conta A para a conta B. São dois passos: tirar de A e colocar em B. Se o sistema cair entre os dois, o dinheiro some. Uma transação resolve isso: junta os passos num pacote que acontece inteiro ou não acontece. Se algo falha no meio, o banco desfaz tudo (rollback).

As garantias de uma transação têm um apelido: ACID.

• Atomicidade: tudo ou nada.
• Consistência: o banco sai de um estado válido e chega a outro estado válido (as regras, como “saldo não negativo”, continuam valendo).
• Isolamento: uma transação não deve enxergar o trabalho pela metade de outra. No nível mais forte (SERIALIZABLE), o resultado é o mesmo de rodá-las uma de cada vez; níveis mais fracos aceitam algumas interferências em troca de velocidade (veja a tabela mais abaixo).
• Durabilidade: depois do COMMIT, o resultado não se perde, nem se a energia cair.

E índice é o índice remissivo de um livro: em vez de ler o livro inteiro para achar “normalização”, você vai ao índice e salta para a página certa. No banco, um índice numa coluna evita ler a tabela inteira a cada consulta. O custo: o índice ocupa espaço e precisa ser atualizado a cada inserção.

Frase para guardar: transação é tudo ou nada, com ACID; índice acelera a leitura e encarece a escrita.

Em 1 minuto

• Comandos: BEGIN (ou START TRANSACTION), COMMIT confirma, ROLLBACK desfaz, SAVEPOINT marca um ponto para desfazer parcialmente.
• Anomalias de concorrência: leitura suja (ler o que outra transação ainda não confirmou), leitura não repetível (ler duas vezes a mesma linha e achar valores diferentes), leitura fantasma (repetir a consulta e aparecerem linhas novas) e atualização perdida (duas transações leem o mesmo saldo e gravam por cima, e a alteração de uma some).
• Níveis de isolamento do SQL padrão, do mais fraco ao mais forte: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ e SERIALIZABLE.
• Deadlock: duas transações esperam uma pela outra; o SGBD escolhe uma vítima e a desfaz.
• Índice B-tree serve para igualdade, faixas e ordenação; hash, só para igualdade. Índice composto vale para consultas que usam as primeiras colunas dele.

Exemplo concreto: o pagamento de uma diária

BEGIN;
UPDATE orcamento SET saldo = saldo - 800 WHERE setor = 'TI';
INSERT INTO pagamento (servidor, valor, data) VALUES ('Ana', 800, CURRENT_DATE);
COMMIT;          -- as duas mudanças ficam valendo juntas
-- Se o INSERT falhar, ROLLBACK: o saldo volta ao que era

Agora a consulta lenta: “pagamentos da Ana em 2026”.

SELECT * FROM pagamento WHERE servidor = 'Ana' AND data >= '2026-01-01';

Com um milhão de linhas e sem índice, o banco lê a tabela inteira (varredura completa). Com um índice composto em (servidor, data), ele salta direto para as linhas da Ana em 2026:

CREATE INDEX idx_pagamento_servidor_data ON pagamento (servidor, data);

Esse índice também serve muito bem para WHERE servidor = 'Ana'. Para WHERE data >= '2026-01-01' sozinho, em regra não ajuda: as entradas estão ordenadas primeiro por servidor, e as datas de 2026 ficam espalhadas pelo índice inteiro (regra do prefixo à esquerda). Alguns otimizadores ainda conseguem usá-lo em casos especiais (o “index skip scan” do Oracle e, desde a versão 18, do PostgreSQL), mas a regra cobrada em prova é a do prefixo. Para conferir o que o banco faz, usa-se o EXPLAIN, que mostra o plano de execução.

Comparação: níveis de isolamento e o que cada um evita (padrão SQL)

Quanto mais forte o isolamento, menos anomalias e menos concorrência (mais espera e mais bloqueios). O READ COMMITTED é o padrão de vários SGBDs, como o PostgreSQL e o Oracle. Alguns SGBDs vão além do mínimo do padrão (no PostgreSQL, o REPEATABLE READ também evita fantasmas), mas a prova segue a tabela do padrão.

A regra “um clusterizado por tabela” vem do SQL Server e do MySQL. No PostgreSQL não há índice clusterizado permanente: o comando CLUSTER reordena a tabela uma vez, e as mudanças seguintes não mantêm a ordem. No Oracle, o equivalente é a tabela organizada por índice (IOT).

Otimização de consultas: o que faz o índice não funcionar

• Função ou cálculo sobre a coluna no WHERE: WHERE UPPER(nome) = 'ANA' não usa o índice em nome (a não ser que exista um índice nessa expressão).
• LIKE '%ana', com curinga no começo, não aproveita o B-tree; LIKE 'ana%' pode aproveitar (no PostgreSQL, se o banco não usa a collation C, o índice precisa ser criado com text_pattern_ops).
• Coluna pouco seletiva (como “sexo” ou “ativo”), em que o índice quase não filtra.
• SELECT * não impede o índice, mas traz colunas desnecessárias e impede a leitura só no índice (index-only scan); liste só as colunas que precisa.
• Estatísticas desatualizadas levam o otimizador a escolher um plano ruim.

Como a FCC cobra

• Atomicidade × consistência × isolamento × durabilidade num cenário.
• COMMIT, ROLLBACK e SAVEPOINT.
• Leitura suja, não repetível e fantasma.
• Quando o índice ajuda, quando atrapalha e por que uma consulta não usa o índice.

Pegadinhas

Explique com suas palavras

Explique a um colega, com o exemplo de uma transferência, o que significam as quatro letras de ACID, e diga por que não se deve criar índice em todas as colunas.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Numa transferência, tirar o dinheiro de uma conta e colocar na outra tem de acontecer junto: ou as duas coisas, ou nenhuma. Isso é a atomicidade. A consistência garante que as regras continuam valendo, como não deixar saldo negativo. O isolamento faz com que outra operação, ao mesmo tempo, não veja a transferência pela metade. A durabilidade garante que, depois de confirmada, a transferência não se perde nem se a energia cair.

Índice é como o índice de um livro: acelera a busca. Mas cada índice ocupa espaço e precisa ser atualizado a cada inserção ou alteração. Índice em todas as colunas deixaria as gravações lentas para acelerar consultas que talvez nem existam.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Em casos de banco de dados, transações aparecem quando há operações que precisam acontecer juntas (registrar um pagamento e baixar o saldo). Escreva o bloco BEGIN … COMMIT e diga o que acontece com ROLLBACK. Em problemas de desempenho, proponha o índice certo, justificado pela consulta, e a verificação com EXPLAIN.

Fontes da lição

• Edital nº 01/2026, Anexo II, Banco de Dados (fontes/edital-01-2026.txt).
• Ramez Elmasri e Shamkant Navathe, Sistemas de banco de dados (transações, ACID, controle de concorrência e índices).
• Documentação do PostgreSQL: isolamento de transações