MySQL (4) princípio de transação e análise

Artigos da Série MySQL

MySQL (1) Estrutura básica, operação de instrução SQL, experimentando
MySQL (2) Princípio de indexação e otimização
MySQL (3) Otimização SQL, Buffer pool, Change buffer
MySQL (4) Princípio de transação e análise
MySQL (5) Estratégia de cache
MySQL (6) Três paradigmas de banco de dados de replicação mestre-escravo



prefácio

Background : Como mencionado anteriormente, o MySQL pode operar concorrentemente, ou seja, vários clientes MySQL operam o banco de dados em um servidor, então envolve a questão do acesso concorrente, por isso existe o conceito de transação.


Definição : A essência de uma transação é a unidade de controle de concorrência, que é uma coleção de uma série de operações de banco de dados definidas pelos usuários. Essas operações são feitas ou não feitas e são uma unidade indivisível de trabalho.


Composição : Uma transação pode ser composta por uma instrução SQL muito simples ou um conjunto de instruções SQL complexas; no innodb do MySQL, uma única instrução possui uma transação; você pode definir a sessão atual para confirmar manualmente por autocommit = 0;

As transações têm propriedades ACID, ou seja, atomicidade, consistência, isolamento e durabilidade.

Propriedades ACID

Atomicidade (A)

As operações de transação são concluídas (commit) ou não concluídas (rollback); uma transação é uma unidade de execução de programa que acessa e atualiza vários itens de dados no banco de dados e é uma unidade de trabalho indivisível; a operação de rollback é implementada por meio de undolog. O undolog registra as operações específicas de cada etapa da transação. Ao ser revertido, reproduzirá a operação inversa das operações específicas da transação; todas as operações
incluídas na transação são um todo indivisível, sejam todas executadas ou não executado em tudo;

Embora se diga que as transações devem manter a atomicidade, por exemplo, a execução serial completa pode garantir a atomicidade da execução das instruções nas transações; mas o desempenho desse método é muito baixo, então o Mysql geralmente usa a execução cruzada de instruções entre as transações para melhorar o desempenho .

Isolamento (I)

Descrição: O grau de influência mútua entre várias transações ; evita a inconsistência de dados causada pela execução cruzada de várias transações simultâneas, por meio de bloqueios e MVCC.
Objetivo: Estipula principalmente que várias transações acessam o mesmo recurso de dados e o comportamento de cada transação acessando o recurso de dados. Isolamento diferente é para lidar com fenômenos diferentes (leitura suja, leitura não repetível, leitura fantasma); o isolamento de transações requer
cada um Os objetos de transações de leitura e gravação podem ser separados dos objetos de operação de outras transações, e as transações simultâneas não afetarão umas às outras. Diferentes graus de níveis de isolamento são definidos e o desempenho pode ser melhorado quebrando moderadamente a consistência; realizado pelo MVCC e bloqueios ;MVCC é um controle de simultaneidade de várias versões, que resolve principalmente o problema de leituras sem bloqueio consistentes e obtém desempenho de leitura simultânea eficiente registrando e obtendo versões de linha em vez de usar bloqueios para restringir as operações de leitura. Os bloqueios são usados ​​para lidar com operações DML simultâneas; o banco de dados fornece uma estratégia de bloqueios granulares, que são bloqueados em três granularidades: tabelas (árvore B+ de índice agrupado), páginas (nós de folha da árvore B+ de índice agrupado) e linhas (um segmento de registro linhas em nós folha);

Persistência (D)

Uma vez concluída a transação, as alterações feitas nos dados devem ser registradas, incluindo armazenamento de dados e backup de rede multicópia;
após a confirmação da transação, as operações de adição, exclusão e modificação da transação serão persistentes (o deslocamento de página o valor gravado no arquivo do disco redolog é um dado específico); mesmo que ocorram falhas como tempo de inatividade, o banco de dados pode restaurar os dados. Redolog registra logs físicos;

Consistência (C)

Antes e depois da transação, todos os dados mantêm um estado consistente, que não pode violar a verificação de consistência de dados (verificação de restrição de integridade);
consistência significa que a transação altera o banco de dados de um estado consistente para o próximo estado consistente, antes e depois da execução da transação, as restrições de integridade do banco de dados não são violadas; uma unidade de transação precisa ser confirmada antes de ficar visível para outras transações. Por exemplo: o nome de uma tabela é uma chave única, se uma transação modifica o nome, mas depois que a transação é confirmada ou revertida, o nome na tabela torna-se não exclusivo, quebrando assim a consistência; a consistência consiste em atomicidade, isolamento , e persistência são mantidas em conjunto.

nível de isolamento

Quando múltiplas transações são executadas simultaneamente, é necessário considerar o nível de isolamento, ou seja, isolamento diferente. Os padrões SQL ISO e ANIS padronizam em quatro níveis de isolamento de transação, quanto maior o nível de isolamento, menor o desempenho .
Ou seja, os três primeiros níveis de isolamento de READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ e SERIALIZABLE causarão diferentes exceções de leitura simultâneas, ou seja, leitura suja, leitura não repetível e cenários de leitura fantasma.


Diferentes exceções de leitura simultâneas geradas por diferentes níveis de isolamento:
leitura suja : uma transação lê dados modificados por outra transação não confirmada;
leitura não repetível : uma transação lê os mesmos dados duas vezes;
leitura fantasma : uma transação Os conjuntos de resultados obtidos pela leitura dos registros em o mesmo intervalo duas vezes no mesmo intervalo são diferentes;

A diferença entre
leituras sujas e leituras não repetíveis é que as leituras sujas leem dados não confirmados de outra transação, enquanto as leituras não repetíveis leem modificações após a confirmação de outra transação; essencialmente, todas são modificadas por outras transações A leitura desta transação;
não leitura repetível e leitura fantasma são semelhantes; leitura não repetível é ler o mesmo registro duas vezes e obter resultados diferentes; leitura fantasma é obtida lendo os registros no mesmo intervalo duas vezes Os conjuntos de resultados são diferentes (o número pode ser diferente, ou o mesmo número pode ser diferente, por exemplo, uma nova linha é adicionada após uma linha de x); leitura não repetível é porque outras transações realizaram uma operação de atualização e leitura fantasma é porque outras transações executaram uma inserção ou exclusão Operação.


O nível de isolamento padrão suportado pelo MySQL innodb é REPEATABLE READ;

LEIA SEM COMPROMISSO

Leitura não confirmada; as operações de leitura neste nível não bloqueiam, as operações de gravação adicionam bloqueios exclusivos e os bloqueios de gravação são liberados após a confirmação ou reversão da transação; portanto, os dados antes das reversões da transação podem ser lidos, resultando em leituras sujas.

LER COMPROMETIDO

Read Committed (RC); sob este nível de isolamento, são lidos os dados mais recentes da versão histórica, então os dados confirmados são lidos; ocorre leitura não repetível.

LEITURA REPETÍVEL

Leitura repetível (RR); neste momento, a operação de leitura lê os dados da versão no início da transação; ocorrerá leitura fantasma. Você pode usar a leitura atual, ou seja, bloquear a leitura para resolver o fenômeno de leitura fantasma.

SERIALIZÁVEL

Serializável; neste nível, um bloqueio compartilhado é adicionado à leitura; portanto, as transações são executadas em série; neste momento, o nível de isolamento é o mais rigoroso;

bloqueio compartilhado e bloqueio exclusivo

Para resolver o problema de exceções de leitura simultâneas, o banco de dados introduz um mecanismo de bloqueio. Os bloqueios são divididos em bloqueios compartilhados e bloqueios exclusivos. Os bloqueios compartilhados permitem que várias transações leiam os mesmos dados ao mesmo tempo, mas não podem modificá-los; os bloqueios exclusivos permitem que apenas uma transação modifique os dados.

MVCC

MVCC é uma tecnologia de controle de simultaneidade de várias versões que pode ser usada para resolver exceções de leitura simultâneas e leituras fantasmas sem bloqueio . O MVCC obtém o isolamento criando uma versão separada para cada transação, cada versão contendo todos os dados que a transação viu durante a execução. Quando várias transações acessarem os mesmos dados ao mesmo tempo, o sistema julgará se deve permitir o acesso de acordo com o número da versão de cada transação.

A multiversão depende principalmente do log Undo-log para alcançar, enquanto o controle de simultaneidade é obtido através do campo oculto da tabela + instantâneo ReadView

Para obter detalhes, consulte: https://maimai.cn/article/detail?fid=1760762705&efid=UVf-Pw63L4lRkESvTUv1AQ

vista de leitura

Sob os níveis de isolamento de leitura confirmada e leitura repetível, o MVCC usa a visualização de leitura para implementar. A diferença entre eles é que o tempo de criação da visualização de leitura é diferente:

O nível de isolamento de confirmação de leitura gerará uma nova exibição de leitura para cada seleção em uma transação, o que também significa que a leitura do mesmo dado várias vezes na mesma transação pode causar inconsistência de dados; há uma situação de leitura não repetível. Como outras transações podem modificar o registro e enviá-lo durante várias leituras, o
nível de isolamento repetível de leitura é gerar uma exibição de leitura quando a transação é iniciada e usar essa exibição de leitura somente quando os dados são lidos em toda a transação, o que garante que Os dados lidos durante a transação são todos registros antes do início da transação, o que resolve o problema de leitura não repetível.

refazer

O redo log é usado para obter a persistência da transação; a memória contém o buffer de redo log e o disco contém o arquivo de redo log;
quando a transação é confirmada, todos os logs da transação devem primeiro ser gravados no redo log arquivo para persistência. A operação de confirmação da transação é concluída antes que a transação seja confirmada;
o redo log é gravado sequencialmente, registrando a modificação de cada página (página, deslocamento de página e conteúdo modificado); não há necessidade de editar o redo arquivo de log quando o banco de dados está em execução Executa operações de leitura; somente quando ocorre um tempo de inatividade, o redo log é usado para recuperação;

desfazer

O log de desfazer é usado para ajudar na reversão da transação e na função MVCC; ele é armazenado no espaço de tabela compartilhado; desfazer é um log lógico, que restaura logicamente o banco de dados ao seu estado original ao retroceder e executa a operação reversa anterior de acordo com o desfazer registros de log; Por exemplo, se houver uma operação de inserção na transação, execute a operação de exclusão; para a operação de atualização, execute a operação de atualização oposta; ao mesmo tempo,
o log de desfazer registra as informações de versão da linha, que é usado para processar a função MVCC;

Acho que você gosta

Origin blog.csdn.net/weixin_44477424/article/details/131741487
Recomendado
Clasificación