Uma transação agrupa comandos em uma unidade atômica: ou todos confirmam (commit) ou todos revertem (rollback), dando o A, C, I, D do ACID. O nível de isolamento ajusta o "I" — o quanto transações concorrentes conseguem ver dos dados não confirmados ou em mudança umas das outras.
| Nível | Dirty read | Non-repeatable read | Phantom |
|---|
| READ UNCOMMITTED | possível | possível | possível |
| READ COMMITTED | não | possível | possível |
| REPEATABLE READ (padrão do InnoDB) | não | não | quase nunca* |
| SERIALIZABLE | não | não | não |
*O REPEATABLE READ do InnoDB usa MVCC (cada transação lê um snapshot consistente) mais next-key locks, então bloqueia a maioria dos phantoms também — mais forte do que o padrão SQL exige.
SELECT @@transaction_isolation; -- REPEATABLE-READ by default
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- snapshot taken here
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- both updates apply, or ROLLBACK undoes both
Mantenha o padrão do InnoDB (REPEATABLE READ) a menos que tenha um motivo. READ COMMITTED (o padrão de Postgres/Oracle) reduz a contenção de bloqueios em sistemas com muita escrita; SERIALIZABLE é correto, mas serializa trabalho conflitante e pode gerar mais deadlocks.
O isolamento é o dial entre correção e concorrência. Entender essas anomalias permite explicar bugs como "o total não bateu sob carga" e escolher um nível que mantenha transações que movem dinheiro corretas sem estrangular a vazão desnecessariamente.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar