Suponha que exista uma tabela "Bank_Account" e contenha uma única coluna "balance", onde todos têm saldo = 100.
Se uma transação executar "atualizar Bank_Account set balance = 200 onde 1=1; commit;" É possível que quaisquer 2 transações executando uma seleção na tabela Bank_Account tenham uma leitura 200 e outra leitura 100 para uma conta bancária diferente?
Ou uma vez retornado 200 para uma determinada conta bancária, todas as outras necessariamente retornarão 200 também porque o commit foi atômico?
Minha intuição no banco de dados seria que uma vez que alguém lê 200, todos os outros devem ler 200 porque uma transação é atômica, mas também li que algumas seleções podem ser executadas sem bloquear a tabela ou linhas e retornar um instantâneo dos dados no início de uma transação, mesmo assumindo o nível de isolamento de leitura confirmada.
Se for esse o caso, como os bancos de dados implementam esse comportamento sem bloqueios? Que mágica o commit e os selects realizam para garantir que os selects operem em um comportamento atômico, tudo ao mesmo tempo, de um commit?
Obrigado
COMMIT é atomic , ou toda a transação foi confirmada ou nada dela.
Se você usar um mecanismo de banco de dados que suporte simultaneidade (ou seja, não MyISAM), cada consulta verá o banco de dados como estava quando o instantâneo foi obtido. No nível de isolamento "leitura confirmada", o instantâneo é obtido no início da consulta, uma vez por consulta. Na “leitura repetível”, o instantâneo é obtido no início da transação.
Aqui estão dois clientes conectados a um servidor de banco de dados realizando consultas simultaneamente. Assumindo READ COMMITTED:
Nesse caso, o SELECT do cliente 2 verá a versão mais antiga do material, porque o cliente 1 ainda não foi confirmado quando o SELECT tira seu instantâneo. Isso é verdade mesmo que o SELECT demore um pouco para ser executado e o client1 seja confirmado antes de ser concluído, pois o instantâneo do SELECT foi obtido antes do commit do client1.
Para implementar isso, o banco de dados deve manter uma cópia de todas as versões de uma linha que ainda possa ser necessária. Isso inclui versões anteriores de linhas atualizadas por uma transação que ainda não foi confirmada, todas as versões ainda visíveis por um instantâneo ativo, etc. É bastante complicado.
Uma maneira de fazer isso é o MVCC , que pode ser implementado de diferentes maneiras, cada uma com suas próprias vantagens: novas versões podem ser armazenadas na tabela junto com a versão antiga, mas isso incha a tabela, cria buracos quando são excluídas e requer que algum espaço livre seja mantido em cada página para ser eficiente. Ou versões antigas podem ser movidas para um "armazenamento de versões" ou "registro de desfazer" e a nova versão armazenada no lugar da antiga, mas em caso de reversão isso requer mover todas as versões antigas de volta para onde estavam.
Também existem fechaduras por toda parte.
Existem bloqueios internos que são invisíveis para o cliente: por exemplo, quando ele modifica uma página, provavelmente irá bloqueá-la enquanto escreve a linha nela para garantir que os ponteiros, contagens, etc. acabem em um estado coerente. Este tipo de bloqueio não é mantido durante uma transação, ele é mantido apenas para fazer o que é necessário, normalmente escrever algumas coisas na memória, por isso é muito curto.
Depois, há bloqueios que ficam visíveis para o cliente: quando você faz um UPDATE, o banco de dados irá colocar um bloqueio naquela linha até você COMMIT. Portanto, se outro cliente tentar atualizar essa linha específica, ele terá que esperar até você confirmar ou reverter. Caso contrário, não saberia qual versão da linha o UPDATE obtém. A questão toda é que esse tipo de bloqueio não bloqueia leituras, então a linha ainda pode ser selecionada.
O importante é que não haja bloqueios em toda a tabela, pois isso destrói absolutamente o desempenho.
Caso suas consultas tenham bloqueios, é importante tentar liberá-los o mais rápido possível.