Níveis de isolamento

O problema: transações simultâneas se enxergam

O tópico de transações mostrou que uma transação é tudo ou nada. Mas, enquanto ela roda, outras rodam ao mesmo tempo, lendo e escrevendo as mesmas tabelas. O nível de isolamento decide o quanto uma enxerga das outras.

O isolamento perfeito seria cada transação rodar como se estivesse sozinha no banco, uma depois da outra. Isso tem um custo: travas, esperas e transações recusadas. Por isso os bancos oferecem níveis intermediários, que deixam passar algumas anomalias em troca de desempenho. E vêm configurados num desses níveis intermediários.

As cinco anomalias

As três primeiras são problemas de leitura. As duas últimas são as que corrompem dados, e são as que mais aparecem em código de aplicação.

O que cada nível permite, medido

O padrão SQL define quatro níveis: read uncommitted, read committed, repeatable read e serializable. Reproduzimos cada anomalia em cada nível, no PostgreSQL 18 e no MySQL 8.4 (InnoDB), com duas transações intercaladas passo a passo.

PostgreSQL 18 (padrão: read committed)

MySQL 8.4 (padrão: repeatable read)

O PostgreSQL não tem leitura suja em nenhum nível: pedir read uncommitted dá read committed.

A diferença que mais engana

O nível tem o mesmo nome nos dois bancos e não se comporta igual. A linha da atualização perdida mostra isso:

• No PostgreSQL em repeatable read, a segunda transação a gravar recebeu o erro 40001 (could not serialize access due to concurrent update). O saque não se perdeu: a aplicação recebeu um erro e pode repetir.
• No MySQL em repeatable read, o nível padrão dele, a segunda transação gravou por cima, sem erro nenhum. O saldo terminou em 90 depois de dois saques de 10.

O mesmo código, com o mesmo nome de nível, está protegido num banco e perde dinheiro no outro.

O MySQL tem outra particularidade no repeatable read. A leitura enxerga uma fotografia do começo da transação, mas escritas enxergam o dado atual. Testamos: a transação contou 1 conta, outra transação inseriu uma segunda conta e confirmou, e a primeira contou de novo, ainda 1. Até aqui, sem fantasma. Então a primeira executou UPDATE contas SET saldo = saldo + 1 WHERE saldo > 0, que alterou 2 linhas, inclusive a que ela não enxergava. A contagem seguinte, na mesma transação, mostrou 2. No PostgreSQL, o mesmo UPDATE alterou 1 linha, e a contagem continuou 1.

A escrita enviesada

A anomalia mais difícil de perceber merece um exemplo completo. A regra: pelo menos um médico fica de plantão. Ana e Bia estão de plantão, e as duas pedem para sair ao mesmo tempo:

transação da Ana                          transação da Bia
SELECT count(*) ... de_plantao  → 2
                                          SELECT count(*) ... de_plantao  → 2
"sobra uma, posso sair"
UPDATE ... WHERE medico = 'ana'
                                          "sobra uma, posso sair"
                                          UPDATE ... WHERE medico = 'bia'
COMMIT
                                          COMMIT

Cada transação conferiu a regra corretamente, com os dados que via. As duas alteraram linhas diferentes, então nenhuma trava de linha as impediu. No fim, ninguém ficou de plantão. No PostgreSQL, isso aconteceu em read committed e em repeatable read. Só o serializable recusou uma das duas.

Na Implementação, dez médicos pedem para sair ao mesmo tempo. Com read committed, os dez saíram e ninguém ficou. Com serializable e a repetição das transações recusadas, saíram nove, e um ficou, nas cinco linguagens.

Serializable: correto, e às vezes recusa

O nível serializable garante que o resultado é igual ao de alguma execução em fila, uma transação depois da outra. Os dois bancos chegam lá por caminhos diferentes:

Nos dois, a transação recusada precisa ser repetida do começo pela aplicação. Sem a repetição, o serializable troca dados errados por erros na cara do usuário.

Por que isso importa quando a IA escreve o código

Um assistente que escreve uma regra de negócio com transação costuma assumir que "estar numa transação" basta:

• Ler, calcular na aplicação e gravar, sem trava nem condição, no nível padrão.
• Regras que olham várias linhas ("no máximo três reservas", "pelo menos um de plantão") conferidas com um SELECT antes de gravar.
• Serializable ligado sem repetir as transações recusadas.
• Repetição de qualquer erro, e não só do erro de serialização.
• Código testado num banco e levado para outro, contando com o mesmo comportamento do mesmo nível.

O próximo nível compara as formas de proteger cada anomalia, com o custo de cada uma.