contente
Declarações de controle para transações comuns
Características ACID das transações
Persistência (gravar o log primeiro e depois gravar no disco, eficiente)
Exceção de simultaneidade transacional
Leitura não repetível (ler + ler, o resultado é diferente)
Leitura fantasma (ler + escrever, pensar que leu, ir escrever, mas não existe)
Nível de isolamento da transação
Conhecimento simples dos níveis de isolamento
Compreensão transacional
composição da transação
- Em termos simples, uma transação pode consistir em uma instrução sql simples ou um conjunto de instruções sql complexas ( uma transação é uma unidade lógica de programa )
Características da transação
- Quando o banco de dados confirma uma transação, todas as modificações são salvas ou todas as modificações são descartadas ( atômica, toda a transação é concluída ou toda a transação é descartada )
- Uma transação é uma unidade de execução de programa que acessa e atualiza vários itens de dados em um banco de dados
- O mecanismo innodb do mysql suporta transações, myisam não suporta transações , e cada instrução sql no innodb é uma transação; se quisermos cancelar a transação de confirmação automática, podemos definir a sessão atual para confirmar manualmente a transação definindo set autocommit = 0;
Declarações de controle para transações comuns
-- 显示的开启事务
start transaction | begin;
-- 提交事务，并且对于当前数据库所作的操作修改做持久化
commit;
-- 回滚事务，结束用户的事务，并撤销正在进行的所有未提交的修改
rollback;
-- 创建一个保存点，一个事务可以有多个保存点
savepoint identifier
-- 删除一个保存点
release savepoint identifier
-- 事务回滚到保存点
rollback to [savepoint] identifier
Características ACID das transações
Atomicity (compreensão de onde os dados globais podem ser gravados com a ajuda de multi-threading) unidade de operação de ligação
- Compreensão superficial: Isso é fácil de entender, o que significa que uma transação deve ser uma unidade de sequência de operação atômica e todas as operações podem permitir apenas dois estados em um processo de execução - todas as execuções são bem-sucedidas ou todas as execuções falham ( vinculadas em uma transação todas as operações em )
- Entendimento aprofundado: as operações de transação são feitas (commit) ou não feitas (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 inseparável ; o rollback é obtido por meio de undolog operar. O undolog registra a operação específica de cada etapa da transação. Quando é revertido, a operação inversa da operação específica da transação é reproduzida ; (o princípio do rollback é seguir o undolog de volta para restaurar o estado anterior ao Operação)
isolamento
- A execução de uma transação não pode ser interferida por outras transações.
- Para explicar o isolamento: Primeiro entenda a simultaneidade das transações.Existem muitos usuários do nosso banco de dados, e as transações podem ser executadas simultaneamente.Isolamento significa que as transações simultâneas são isoladas umas das outras e não interferem umas nas outras . Ou seja, quando diferentes transações operam os mesmos dados simultaneamente, cada transação possui seu próprio espaço de dados independente e completo.
- Compreensão aprofundada do princípio: O isolamento das transações requer que os objetos de cada transação de leitura/gravação possam ser separados dos objetos de operação de outras transações , ou seja, eles não são visíveis para outras transações antes que a transação seja confirmada ; é realizado por meio de MVCC e bloqueios; MVCC é o controle simultâneo de várias versões , que resolve principalmente leituras consistentes sem bloqueio , alcança um desempenho eficiente de leitura simultânea gravando e obtendo versões de linha em vez de usar bloqueios para limitar as operações de leitura. Os bloqueios são usados para lidar com operações DML simultâneas ; o banco de dados fornece estratégias de bloqueio granular para três bloqueios de granularidade: tabela (índice clusterizado B+ árvore), página (índice clusterizado B+ nó folha) e linha (um segmento de linha de registro em um nó folha) .
- O MVCC tem melhor desempenho, evita adicionar operações de leitura de bloqueio de linha e evita espera de bloqueio
Persistência (gravar o log primeiro e depois gravar no disco, eficiente)
- Depois que a transação é confirmada, suas alterações nos dados são persistentes. Uma vez que a transação é confirmada, os dados relacionados devem mudar de um estado livre ou transitório para um estado persistente.
- redo log é um módulo de log específico para o mecanismo InnoDB, que registra: quais alterações foram feitas em uma página de dados;
- Quando o MySQL executa uma instrução de atualização, o mecanismo InnoDB primeiro grava o registro no arquivo de redo log e atualiza a memória. Neste ponto, a operação de atualização está concluída, mas não há disco para persistir a atualização de dados. O mecanismo InnoDB persistirá a operação de atualização de dados no disco em um momento adequado.
- Depois que a transação for confirmada, a operação DML da transação será persistente (qual valor de deslocamento de página do arquivo de disco redolog é gravado nos dados específicos); mesmo se ocorrer uma falha, como tempo de inatividade, o banco de dados pode recuperar os dados. O redo log registra o log físico ; ( significando que todas as operações DML da transação serão gravadas no arquivo de disco do redo log, e a localização e as operações específicas da operação serão registradas no redo log log, portanto, mesmo que haja um tempo de inatividade, etc. também recuperável )
Consistência (é um estado em que a integridade dos dados não é destruída, seja revertida ou confirmada)
- Refere-se à necessidade de manter a integridade e consistência dos dados antes e depois da operação do banco de dados. A execução da transação faz com que o banco de dados seja convertido de um estado de consistência para outro estado de consistência , ou seja, antes e depois do transação é executada, as restrições de integridade do banco de dados não são destruídas. (por exemplo: A conta A transfere 500 yuans para a conta B, é impossível dizer que a conta A diminuiu 500 yuans, mas a conta B não aumentou 500 yuans )
- A consistência é mantida pela atomicidade, isolamento e durabilidade.
Exceção de simultaneidade transacional
leitura suja
- A transação A pode ler dados que ainda não foram confirmados por outra transação B. Os dados não confirmados lidos pela transação A são os chamados dados de leitura suja . Para demonstrar a leitura de dados de leitura suja, primeiro precisamos definir o nível de isolamento para ler não confirmado leia sem compromisso
- Demonstrar leituras sujas
Leitura não repetível (ler + ler, o resultado é diferente)
- A transação (A) pode ler os dados enviados em outra transação (B); geralmente acontece que os dados lidos duas vezes em uma transação não são os mesmos; existem leituras não repetíveis no nível de isolamento READ COMMITTED . De um modo geral, o problema de leitura não repetível é aceitável, pois a leitura dos dados enviados geralmente não causa grandes problemas, portanto, o nível de isolamento padrão de muitos fabricantes (como Oracle, SQL Server) é READ COMMITTED
- A transação A é lida pela primeira vez, a transação B ainda não foi confirmada, a transação A é lida pela segunda vez, a transação B é confirmada e os resultados das duas leituras não serão consistentes
Leitura fantasma (ler + escrever, pensar que leu, ir escrever, mas não existe)
- Uma operação de leitura em uma transação não pode suportar a próxima lógica de negócios; geralmente ocorre quando uma operação de leitura em uma transação determina que a próxima operação de gravação falha ; por exemplo: uma tabela com nome como a chave exclusiva, query select * from t where name em uma transação = 'marca'; não existe, então insira em t(nome) valores ('marca'); ocorre um erro e outra transação também executa uma operação de inserção; leitura fantasma existe em nível de isolamento leitura repetível e abaixo; mas pode ser resolvido lendo bloqueios (usando bloqueios compartilhados) no nível de leitura repetível ;
- Um exemplo simples de leitura fantasma é que a transação A acabou de consultar um registro que não existe e se prepara para fazer uma operação de inserção. Neste momento, outra transação B insere esse registro e o envia. Neste momento, é equivalente para a consulta de registro agora. ilusório, não real, também conhecido como leitura fantasma
- Solução 1: Adicione um bloqueio de leitura compartilhado, um bloqueio de leitura e um bloqueio de intervalo à operação de consulta. Após o bloqueio, outras transações não podem ser alinhadas para operações de inserção. Quando um bloqueio compartilhado é adicionado à consulta, a transação B não pode concluir a operação de inserção. , para evitar o fenômeno da leitura fantasma ( o bloqueio compartilhado no mysql é equivalente ao bloqueio de gravação quando aprendemos o sistema operacional )
- Solução 2: Modifique diretamente o nível de isolamento da transação para ler sequencialmente: serializável, a operação de leitura adicionará automaticamente o compartilhamento de bloqueio compartilhado no modo após a serialização , mas basicamente não é recomendado, a eficiência é muito baixa, o bloqueio aguarda, e o desempenho diminui terrivelmente.
Nível de isolamento da transação
-
Conhecimento simples dos níveis de isolamento
- Quanto maior o nível de isolamento da transação, mais seguro será, mas a eficiência se tornará cada vez menor, e a simultaneidade se tornará cada vez pior
- O nível padrão geralmente é leitura confirmada ou leitura repetível
- Os padrões ISO e ANIS SQL formularam quatro padrões de nível de isolamento de transação.Cada fabricante de banco de dados fez compromissos entre correção e desempenho, e não seguiu estritamente esses padrões; o nível de isolamento suportado pelo MySQL innodb por padrão é REPEATABLE READ ;
-
A implementação subjacente do nível de isolamento (mvcc + vários bloqueios) mvcc + vários bloqueios são para garantir o isolamento, atomicidade e outras propriedades entre transações em execução simultânea
- READ UNCOMMITTED leitura não confirmada; leitura não está bloqueada neste nível, bloqueio exclusivo de gravação, bloqueio de gravação é liberado após confirmação ou reversão da transação ( leitura não confirmada, leitura neste nível não será bloqueada e não há mvcc )
- READ COMMITTED A leitura foi confirmada; a leitura neste nível não será bloqueada automaticamente, mas mvcc (controle de simultaneidade de várias versões) é adotado, que é fornecer uma leitura consistente sem bloqueio, e a operação de leitura lê dados históricos de instantâneos em desta vez; este isolamento Os dados mais recentes da versão histórica são lidos sob o nível, então os dados enviados são lidos; ( É justamente porque os dados mais recentes da versão histórica, ou seja, os dados enviados atualmente, são lidos, então leitura repetida não é suportada, porque existem outros A transação faz um novo envio, e o resultado da leitura repetida da transação será inconsistente com o anterior ao envio )
- REPEATABLE READ Leitura repetível; MVCC também é suportado neste nível, e a operação de leitura lê os dados da versão no início da transação
- Ou seja, como a leitura repetível suporta leitura repetível, não importa quantas novas versões você envie, eu sempre leio apenas a primeira versão da transação aberta, ou seja, minha primeira versão de dados históricos, a versão mais recente do instantâneo histórico dados enviados por outras transações eu não vou prestar atenção. ( Como eu tenho lido a primeira versão dos dados, naturalmente isso não causará o problema de inconsistência de dados repetidos devido à versão mais recente dos dados. Esta é uma leitura repetível, então agora eu entendo por que ele pode suportar a leitura repetida de dados consistentes )
- SERIALIZABLE pode ser serializado; neste nível, um bloqueio compartilhado (bloqueio S) é adicionado à leitura; portanto, as transações são executadas em série; o nível de isolamento é o mais rigoroso no momento ;
pequeno resumo
- Em primeiro lugar, este capítulo aprende principalmente a definição de transações, entende a natureza importante das transações e inicialmente entende por que lock + mvcc suporta operações de execução de várias transações simultâneas (e entende a implementação subjacente de vários níveis de isolamento)
- O que é uma transação: uma instrução SQL simples ou uma coleção de várias instruções SQL complexas
- Quais propriedades as transações precisam garantir:
- Atomicidade: A operação de reversão do log de desfazer garante que todas as instruções SQL sejam executadas com êxito ou todas tenham falhado.
- Isolamento: mvcc + lock garante que cada transação das operações de leitura e escrita seja isolada uma da outra e não interfira entre si.A operação de escrita deve ser adicionada com x lock, e a operação de leitura é dividida em versões.
- ler não confirmado não bloqueará nem mvcc
- leitura confirmada Há controle de simultaneidade de várias versões do mvcc, leitura fantasma pode ocorrer, pode ser evitada pelo bloqueio compartilhado s, leia a versão mais recente dos dados, há um problema de leitura não repetível,
- A leitura repetível lê a versão mais antiga dos dados para evitar o problema de inconsistência de dados repetidos, mas a leitura fantasma também pode ocorrer, a solução é adicionar s bloqueio compartilhado
- serializável: leitura sequencial, bloqueio s automático para operação de leitura, absolutamente seguro, mas a simultaneidade é a pior
- Persistência: use o redo log para suportar a persistência, modifique o endereço físico dos dados do mysql + como modificar o registro do log, mesmo que esteja inativo, você pode usar o redo log log para recuperação
- Consistência: Garanta a integridade dos dados antes e depois da transação e converta de um estado de consistência para outro estado de consistência. A garantia de consistência depende das três propriedades acima
- read commitado Ler a versão mais recente dos dados terá o problema de leitura não repetível ( os dados lidos são os resultados diferentes antes e depois do commit de outras transações )
- leitura repetível: leitura repetível, leia a primeira versão dos dados históricos do instantâneo, para evitar resultados inconsistentes de leitura repetida, mas pode haver um fenômeno de leitura fantasma, leitura fantasma, leitura + gravação e operação de atualização de acordo com o resultado da leitura. Pergunta, acabei de ler, outras transações foram atualizadas + confirmadas. Neste momento, o resultado da seleção anterior já está incorreto, e os dados lidos antes são os dados de leitura fantasma ( como evitar, mais o s lock )
Deixe um post, uma explicação detalhada de vários bloqueios no mysql, bloqueios ----" Transações são muito importantes