[Intermediário] Análise detalhada do nível de isolamento da transação

[Intermediário] Análise detalhada do nível de isolamento da transação

Este artigo apresenta os quatro níveis de isolamento de transação em detalhes e usa exemplos para ilustrar que tipo de fenômeno de leitura diferentes níveis podem resolver. E introduziu o princípio de realização de diferentes níveis de isolamento em bancos de dados relacionais.

No SGBD, as transações garantem que uma sequência de operações possa ser executada todas ou nenhuma (atomicidade), de um estado para outro (consistência). Porque o negócio satisfaz a durabilidade. Portanto, uma vez que a transação é enviada, os dados podem ser persistidos, e porque a transação satisfaz o isolamento, quando várias transações processam os mesmos dados ao mesmo tempo, várias transações diretamente não afetam umas às outras, portanto, No processo de operações simultâneas de várias transações, se o nível de isolamento não for bem controlado, podem ocorrer fenômenos de leitura, como leituras sujas, leituras não repetíveis ou leituras fantasmas.

Entre os quatro atributos ACID de transações de banco de dados, o isolamento é o mais comumente relaxado. Você pode usar o mecanismo de bloqueio do banco de dados ou o mecanismo de controle de simultaneidade de várias versões para obter um nível de isolamento mais alto durante as operações de dados. No entanto, conforme o nível de isolamento do banco de dados aumenta, a simultaneidade de dados também diminui. Portanto, como fazer uma boa troca entre simultaneidade e isolamento tornou-se uma questão crucial.

No desenvolvimento de software, há uma variedade de práticas recomendadas para quase todos os tipos de problema para nossa referência.Muitos SGBDs definem vários "níveis de isolamento de transação" diferentes para controlar o grau de bloqueio e simultaneidade.

Existem quatro níveis de isolamento padrão definidos por ANSI / ISO SQL, do mais alto ao mais baixo: Serializável, Leituras repetidas, Leitura confirmada, Leitura não confirmada.

A seguir apresentará os conceitos, uso e problemas desses quatro níveis de isolamento de transação, por sua vez (fenômeno de leitura)

Leia sem compromisso

---

Leitura não confirmada (READ UNCOMMITTED) é o nível de isolamento mais baixo. Por nome, podemos saber que sob esse nível de isolamento de transação, uma transação pode ler os dados não confirmados de outra transação.

Situação de bloqueio de banco de dados de leitura não confirmada (princípio de implementação)

A transação não bloqueou os dados durante a leitura dos dados.

Ao modificar dados, apenas adicione bloqueios compartilhados em nível de linha aos dados.
fenômeno:

Quando a transação 1 lê uma linha de registros, a transação 2 também pode ler e atualizar esta linha de registros (porque a transação 1 não adiciona nenhum bloqueio aos dados)

Quando a transação 2 atualiza o registro, a transação 1 lê o registro novamente e pode ler a versão modificada do registro da transação 2 (porque a transação 2 apenas adiciona bloqueio de leitura compartilhado, a transação 1 pode adicionar bloqueio de leitura compartilhado para ler Dados), mesmo que a modificação ainda não tenha sido enviada.

Quando a transação 1 atualiza uma linha de registros, a transação 2 não pode atualizar esta linha de registros até o final da transação 1. (Como a transação um par de dados adiciona um bloqueio de leitura compartilhado, a transação dois não pode adicionar um bloqueio de gravação exclusivo para modificar os dados)

Por exemplo

事务一 事务二
/* Query 1 */
 SELECT age FROM users WHERE id = 1;  
/* will read 20 */  

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 /* No commit here */
 /* Query 1 */
SELECT age FROM users WHERE id = 1;
/* will read 21 */  

 ROLLBACK;
/* lock-based DIRTY READ */

A seguir, utilizamos o exemplo que dei no artigo Analysis of Database Read Phenomenon para ilustrar o isolamento entre duas transações no nível de isolamento de leitura não confirmada.

A transação foi consultada duas vezes no total. Durante as duas consultas, a transação dois modificou os dados sem confirmar. Mas a segunda consulta da transação um encontrou o resultado modificado da transação dois. Na análise do fenômeno da leitura do banco de dados, introduzimos esse fenômeno, que chamamos de leitura suja.

Portanto, leituras não confirmadas levarão a leituras sujas

Leia comprometido

---

READ COMMITTED também pode ser traduzido em read commited.Também pode ser analisado por nome.No processo de modificação dos dados de uma transação, se a transação não foi confirmada, outras transações não podem ler os dados.

Status de bloqueio de banco de dados para leitura de confirmação

A transação adiciona um bloqueio compartilhado em nível de linha aos dados lidos atualmente (o bloqueio só é adicionado quando é lido), uma vez que a linha é lida, o bloqueio compartilhado em nível de linha é liberado imediatamente;

No momento em que uma transação atualiza certos dados (ou seja, o momento em que a atualização ocorre), um bloqueio exclusivo de nível de linha deve ser adicionado a ela primeiro e não será liberado até que a transação termine.

fenômeno:

A transação 1 lê uma linha de registros em todo o processo, a transação 2 pode ler a linha de registros (porque a transação para a linha de registros para aumentar o bloqueio compartilhado em nível de linha, a transação dois também pode aumentar o compartilhamento de dados Trave para ler dados.).

No momento em que a transação 1 lê uma linha, a transação 2 não pode modificar os dados da linha, mas enquanto a transação 1 terminar de ler os dados da linha alterados, a transação 2 pode modificar os dados da linha. (Uma transação adicionará um bloqueio compartilhado aos dados no momento em que é lida, e nenhuma outra transação pode adicionar um bloqueio exclusivo à linha de dados. No entanto, assim que a transação terminar de ler a linha de dados, o bloqueio compartilhado de nível de linha será liberado. Assim que o bloqueio for liberado , A transação dois pode adicionar bloqueio exclusivo aos dados e modificar os dados)

Quando a transação 1 atualiza uma linha de registros, a transação 2 não pode atualizar esta linha de registros até o final da transação 1. (Quando a transação um atualiza os dados, ela adiciona um bloqueio exclusivo aos dados da linha e o bloqueio será liberado até que a transação termine. Portanto, antes que a transação dois seja confirmada, a transação um pode ler os dados sem adicionar um bloqueio compartilhado aos dados. Portanto, enviar a leitura pode resolver o fenômeno de leitura suja)

Por exemplo

事务一 事务二
/* Query 1 */
 SELECT * FROM users WHERE id = 1;  

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 COMMIT;
 /* in multiversion concurrency control, or lock-based READ COMMITTED */ 
 /* Query 1 */
SELECT * FROM users WHERE id = 1;
 COMMIT; 
/*lock-based REPEATABLE READ */ 

No nível de isolamento de leitura de confirmação, a transação um não pode ler dados antes de a transação dois ser confirmada. Somente depois que a transação dois for confirmada, a transação um poderá ler os dados.

Mas, a partir do exemplo acima, também vemos que os resultados de uma ou duas leituras da transação não são consistentes, portanto, enviar a leitura não pode resolver o fenômeno das leituras não repetíveis.

Resumindo, o nível de isolamento da leitura de confirmação garante que qualquer leitura de dados seja confirmada e evita leituras sujas. Mas não há garantia de que os mesmos dados possam ser lidos quando a transação for relida, porque outras transações podem modificar os dados apenas lidos após cada leitura de dados.

Leituras repetidas

---

Leituras repetíveis (READS REPEATABLE), devido ao nível de isolamento de leitura enviado, produzirão leituras não repetíveis. Portanto, um nível de isolamento um nível superior ao das leituras enviadas pode resolver o problema de leituras não repetíveis. Este nível de isolamento é chamado de leitura repetida (este nome é muito caprichoso!)

Situação de bloqueio de banco de dados de leitura repetível

No momento em que uma transação lê certos dados (ou seja, o momento em que começa a ler), um bloqueio compartilhado de nível de linha deve ser adicionado a ela primeiro e não será liberado até o final da transação;

No momento em que uma transação atualiza certos dados (ou seja, o momento em que a atualização ocorre), um bloqueio exclusivo de nível de linha deve ser adicionado a ela primeiro e não será liberado até que a transação termine.

fenômeno

A transação 1 lê uma linha de registros em todo o processo, a transação 2 pode ler a linha de registros (porque a transação para a linha de registros para aumentar o bloqueio compartilhado em nível de linha, a transação dois também pode aumentar o compartilhamento de dados Trave para ler dados.).

A transação 1 está em todo o processo de leitura de uma linha de registros, a transação 2 não pode modificar os dados dessa linha (a transação 1 adicionará um bloqueio compartilhado aos dados durante todo o processo de leitura e o bloqueio não será liberado até que a transação seja confirmada, portanto, todo o processo, Nenhuma outra transação pode adicionar um bloqueio exclusivo à linha de dados. Portanto, leituras repetíveis podem resolver o fenômeno de leituras não repetíveis)

Quando a transação 1 atualiza uma linha de registros, a transação 2 não pode atualizar esta linha de registros até o final da transação 1. (Quando a transação um atualiza os dados, ela adiciona um bloqueio exclusivo aos dados da linha e o bloqueio será liberado até que a transação termine. Portanto, antes que a transação dois seja confirmada, a transação um pode ler os dados sem adicionar um bloqueio compartilhado aos dados. Portanto, enviar a leitura pode resolver o fenômeno de leitura suja)

Por exemplo

事务一 事务二
/* Query 1 */
 SELECT * FROM users WHERE id = 1; 
 COMMIT;    

 /* Query 2 */ 
UPDATE users SET age = 21 WHERE id = 1;
 COMMIT;
 /* in multiversion concurrency control, or lock-based READ COMMITTED */ 

No exemplo acima, somente após a transação um ser confirmada, a transação dois pode alterar a linha de dados. Portanto, enquanto for o período do início ao fim da transação, não importa quantas vezes ele leia a linha de dados, o resultado é o mesmo.

Do exemplo acima, podemos tirar uma conclusão: O nível de isolamento de leitura repetível pode resolver o fenômeno da leitura não repetível. Mas, no nível de isolamento da leitura repetível, há outro fenômeno de leitura que ele não consegue resolver, ou seja, a leitura fantasma. Veja o seguinte exemplo:

事务一 事务二
/* Query 1 */
 SELECT * FROM users WHERE age BETWEEN 10 AND 30;   

 /* Query 2 */ 
INSERT INTO users VALUES ( 3, 'Bob', 27 );
 COMMIT;
 /* Query 1 */
SELECT * FROM users WHERE age BETWEEN 10 AND 30;    

A execução e os fenômenos das duas transações acima são os seguintes:

1. A primeira condição de consulta da transação um é a idade ENTRE 10 E 30; se for dez, os registros atendem à condição. Nesse momento, ele adicionará bloqueios compartilhados em nível de linha aos dez registros elegíveis. Nenhuma outra transação pode alterar esses dez registros.

2. A transação dois executa uma instrução sql, o conteúdo da instrução é inserir um pedaço de dados na tabela. Como nenhuma transação adiciona bloqueios de nível de tabela à tabela neste momento, a operação pode ser executada sem problemas.

3. Quando a transação um executa SELECT * FROM usuários WHERE age BETWEEN 10 AND 30; novamente, os registros retornados tornam-se onze, um a mais do que o agora, e o adicionado é exatamente aquele que acabou de ser inserido pela transação dois.

Portanto, os resultados das duas consultas de intervalo da transação um não são os mesmos. Esta é a leitura fantasma que mencionamos.

Serializável (serializável)

---

Serializable (Serializable) é o nível de isolamento mais alto.Todas as leituras fantasmas que não podem ser resolvidas pelos níveis de isolamento mencionados podem ser resolvidas no nível de isolamento serializável.

Dissemos que o motivo da leitura fantasma é que os bloqueios de intervalo (bloqueios de intervalo: use uma cláusula "WHERE" para descrever os bloqueios de intervalo na consulta SELECT) não são adicionados quando a transação está na consulta de intervalo, o que leva à leitura fantasma.

Situação de bloqueio de banco de dados serializável

Quando uma transação lê dados, ela deve primeiro adicionar um bloqueio compartilhado em nível de tabela e não irá liberá-lo até o final da transação;

Quando uma transação atualiza dados, ela deve primeiro adicionar um bloqueio exclusivo em nível de tabela e liberá-lo até o final da transação.

fenômeno

Quando a transação 1 está lendo os registros na tabela A, a transação 2 também pode ler a tabela A, mas não pode atualizar, adicionar ou excluir a tabela A até que a transação 1 termine. (Como a transação adiciona um bloqueio compartilhado no nível da tabela à tabela, outras transações podem apenas aumentar o bloqueio compartilhado para ler dados e não podem realizar quaisquer outras operações)

Quando a transação 1 está atualizando um registro na tabela A, a transação 2 não pode ler nenhum registro na tabela A, e é impossível atualizar, adicionar ou excluir a tabela A até o final da transação 1. (A transação adiciona bloqueios exclusivos de nível de tabela à tabela, e outras transações não podem adicionar bloqueios compartilhados ou exclusivos à tabela e, portanto, não podem executar nenhuma operação)

Embora a serialização resolva os fenômenos de leitura de leituras sujas, leituras não repetíveis e leituras fantasmas. Mas as transações serializadas terão os seguintes efeitos:

1. Incapaz de ler registros que foram modificados, mas não confirmados por outras transações.

2. Antes que a transação atual seja concluída, outras transações não podem modificar os registros lidos pela transação atual.

3. Antes que a transação atual seja concluída, o valor da chave do índice do novo registro inserido por outras transações não pode estar no intervalo da chave do índice lido por qualquer instrução da transação atual.

Os quatro níveis de isolamento de transação estão ficando cada vez mais altos isoladamente, mas ao mesmo tempo estão ficando cada vez mais baixos em simultaneidade. A razão de haver vários níveis de isolamento é para facilitar aos desenvolvedores a escolha do nível de isolamento mais apropriado de acordo com as necessidades do negócio durante o processo de desenvolvimento.