Maison > base de données > tutoriel mysql > Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

青灯夜游
Libérer: 2023-02-10 19:55:17
avant
1481 Les gens l'ont consulté

Cet article parlera des fonctionnalités de transaction dans MySQL et présentera le principe de mise en œuvre du contrôle de concurrence multi-versions MVCC. J'espère qu'il sera utile à tout le monde !

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

1. Concept

Transaction fait généralement référence à un ensemble logique d'opérations, ou à une série d'opérations effectuées comme une seule unité logique. Toutes les opérations d'une transaction seront encapsulées dans un inséparable dans un. unité d'exécution divisée, toutes les opérations de cette unité réussissent ou échouent. Tant que l'une des opérations échoue, la transaction entière sera annulée.

2. Introduction aux caractéristiques et aux types de transactions

2.1 Caractéristiques des transactions

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

Atomicité (atomicité)

L'atomicité d'une transaction fait référence au fait que toutes les opérations qui la composent la transaction est exécutée avec succès ou toutes les exécutions échouent.

Cohérence

La cohérence d'une transaction signifie que les données sont toujours dans un état cohérent avant et après l'exécution de la transaction.

Isolation

L'isolement des transactions signifie que deux transactions exécutées simultanément n'interfèrent pas l'une avec l'autre. C'est-à-dire que lors de l'exécution d'une transaction, vous ne pouvez pas voir le milieu du processus en cours d'exécution des autres transactions.

?‍Remarque : MySQL是通过锁个MVCCmécanisme pour assurer l'isolement des transactions.

Persistance (durée)

La durabilité d'une transaction signifie qu'une fois la transaction validée, les modifications apportées aux données par cette transaction seront conservées dans la base de données et ne seront pas annulées.

2.2 Introduction à deux types de transactions

  • Transactions locales
  • Transactions distribuées

Transactions locales

Habituellement, les transactions contrôlées sur la base de bases de données relationnelles peuvent être appelées transactions traditionnelles ou transactions locales.

Processus d'exécution des transactions locales

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

  • Avant que le client ne démarre l'opération de transaction, il doit ouvrir une réponse de connexion

  • Après avoir lancé la réponse, le client lance une instruction pour démarrer la transaction ; transaction ;

  • Après le démarrage de la transaction, le client envoie diverses instructions SQL pour traiter les données 

  • Dans des circonstances normales, le client lancera une instruction pour valider la transaction. Si une anomalie se produit, le client lancera. une commande de rollback transaction ;

  • Ce qui précède Une fois le processus terminé, fermez la session.

✔Les affaires locales sont gérées localement par le gestionnaire des ressources.

Les inconvénients des transactions locales sont :

  • n'a pas la capacité de traiter des transactions distribuées
  • Un processus de transaction ne peut se connecter qu'à une seule base de données qui prend en charge les transactions et ne peut pas être utilisé pour plusieurs bases de données transactionnelles.

3. Quels problèmes les transactions simultanées entraîneront-elles ?

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

Perte de mise à jour (écriture sale)

Lorsque deux transactions ou plus exploitent la même ligne de données en même temps et donnent le Quand initial la valeur sélectionnée met à jour la ligne de données, on considère que les transactions ne connaissent pas l'existence de l'autre, donc la dernière opération de mise à jour écrasera les opérations de mise à jour effectuées par d'autres transactions auparavant.

Par exemple :

Le compte de Zhang San est de 100 yuans. Il y a actuellement deux transactions : la transaction 1 et la transaction 2. La transaction 1 consiste à augmenter le solde du compte de Zhang San de 100 yuans, et la transaction 2 consiste à augmenter le solde de Zhang San. de 100 yuans. Ajoutez 200. Initialement, la transaction 1 et la transaction 2 ont lu le solde du compte de Zhang San de 100 yuans en même temps. Ensuite, la transaction 1 et la transaction 2 ont mis à jour Zhang Sanyue respectivement. Les transactions ont été récemment soumises. Le solde de Zhang San est de 300 yuans (normalement, il devrait être de 400 yuans), ce qui signifie : la transaction soumise ultérieurement 2 écrase l'opération de mise à jour de la transaction 1. C'est ce qu'on appelle la perte de mise à jour et la perte de mise à jour. (écriture sale) est essentiellement un conflit d'opérations d'écriture. Cependant, la façon de résoudre les écritures sales est d'exécuter chaque transaction en série pour garantir que les transactions exécutent les opérations d'écriture dans un certain ordre.

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

Dirty read

Une transaction lit les données non validées d'une autre transaction. Par exemple : la transaction 1 ajoute 100 yuans au solde de Zhang San. Avant que cette transaction ne soit soumise, une autre transaction 2 lit les données en cours de modification. S'il n'y a aucune transaction sous contrôle, la deuxième transaction la lira. non soumis est détecté, et la prochaine étape de traitement du cluster de données sales générera une dépendance sur les données non validées. Ce phénomène est généralement appelé Dirty Read脏读,也就是说:脏读是一个事务读取了另一个事务没提交的数据。

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

?脏读本质上是读写操作的冲突,解决方法是先写后读,也就是写完之后再读。

不可重复读

一个事务读取了某些数据,在一段时间后,这个事务再次读取之前读过的数据,此时发现读取的数据发生了变化,或者其中某些数据记录已经被删除,这种现象被称为:不可重复读,即同一个事务,使用同样的查询语句,在不同时刻读取到的结果不一致。

不可重复读的本质上也是读写操作冲突,解决方法是先读后写,也就是读完之后再写。

幻读

一个事务按照相同的查询条件重新读取之前读过的数据,此时发现其他事务插入了满足当前查询条件的新数据,数据结果集变多,这种现象称为幻读,即一个事务两次读取一个范围的数据记录,两次读到的结果不同。

幻读的本质上也是读写操作冲突,解决方法是先读后写,也就是读完之后再写。

那到这里,很多小伙伴就有疑问,同样本质都是读写操作冲突,解决方法是先读后写,不可重复读和幻读到底有何区别?,我下面见简单解释一下:

  • 1️⃣ 不可重复读的重点在于更新和删除操作,而幻读的重点在于插入操作。

  • 2️⃣ MySQL使用锁机制实现事务的隔离级别时,在可重复读隔离级别中,SQL语句第一个读取到数据后,会将相应的数据加锁,使得其他事务无法修改和删除这些数据,通过锁的方式实现可重复读。但是这种方法无法对新数据的插入加锁,如果事务1读取了数据,或者修改和删除了数据,事务2还可以进行插入操作,导致事务1莫名其妙地多了一条之前没有的数据,这就是幻读。

  • 3️⃣ 所以,幻读是无法通过锁机制来避免,需要使用串行化的事务隔离级别,但是这种事务隔离级别会大大降低数据库的并发能力。

✔MySQL是通过MVCC(多版本并发控制)机制来避免不可重复读和幻读的。

四、MySQL事务的隔离级别

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

使用下面的命令可以查询全局级别和会话级别的事务隔离级别:

# 默认数据库的事务隔离级别为:可重复读(REPEATABLE-READ)
SELECT @@global.tx_isolation;
SELECT @@session.tx_isolation;
SELECT @@tx_isolation;
Copier après la connexion

Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL

五、多版本并发控制MVCC

Multi-Version Concurrency Control多版本并发控制,MVCC是一种并发控制的方法,一般在数据库管理系统中,实现对数据库的并发访问。

MVCC比锁的优势

可以将MVCC, c'est-à-dire également :

Dirty. read, c'est lorsqu'une transaction lit des données qui n'ont pas été soumises par une autre transaction. 🎜🎜🎜Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL🎜< blockquote>🎜?La lecture sale est essentiellement un conflit entre les opérations de lecture et d'écriture. La solution est d'écrire d'abord puis de lire, c'est-à-dire de lire après l'écriture. 🎜

🎜Lecture non répétable🎜🎜🎜Une transaction lit certaines données après un certain temps, cette transaction lit à nouveau les données précédemment lues. constaté que les données lues ont changé ou que certains enregistrements de données ont été supprimés, ce phénomène est appelé : lecture non répétable, 🎜c'est-à-dire que la même transaction, utilisant la même instruction de requête, est lue à des moments différents. Les résultats sont incohérents . 🎜🎜
🎜La lecture non répétable est essentiellement un conflit entre les opérations de lecture et d'écriture. La solution est de lire d'abord puis d'écrire, c'est-à-dire d'écrire après lecture. 🎜

🎜Lecture fantôme🎜🎜🎜Une transaction relit les données précédemment lues selon les mêmes conditions de requête. À ce moment, il s'avère que d'autres transactions ont été effectuées. données insérées qui satisfont aux conditions de requête actuelles.Avec de nouvelles données, l'ensemble des résultats des données devient plus grand.Ce phénomène est appelé lecture fantôme, c'est-à-dire qu'une transaction lit deux fois une plage d'enregistrements de données et que les résultats lus deux fois sont différents. 🎜
🎜La lecture fantôme est essentiellement un conflit entre les opérations de lecture et d'écriture. La solution est de lire d'abord puis d'écrire, c'est-à-dire d'écrire après lecture. 🎜
🎜À ce stade, de nombreux amis se posent des questions. La même essence est un conflit entre les opérations de lecture et d'écriture. La solution est de lire d'abord puis d'écrire. Quelle est la différence entre la lecture non répétable et la lecture fantôme ? Je vais expliquer brièvement ci-dessous : 🎜
  • 🎜1️⃣ L'objectif de la lecture non répétable est les opérations de mise à jour et de suppression, tandis que l'objectif de la lecture fantôme est l'insertion. opération. 🎜
  • 🎜2️⃣ Lorsque MySQL utilise le mécanisme de verrouillage pour implémenter des niveaux d'isolement de transaction, dans le niveau d'isolement de lecture répétable, après que la première instruction SQL ait lu les données, les données correspondantes seront verrouillées, de sorte que les autres transactions ne puissent pas modifier ou supprimer ces données, et une lecture reproductible est obtenue grâce à des verrous. Cependant, cette méthode ne peut pas verrouiller l'insertion de nouvelles données. Si la transaction 1 lit les données, ou modifie ou supprime les données, la transaction 2 peut également effectuer une opération d'insertion, ce qui amène la transaction 1 à ajouter inexplicablement une donnée supplémentaire qui n'était pas disponible. avant. C'est une lecture fantôme. 🎜
  • 🎜3️⃣ Par conséquent, les lectures fantômes ne peuvent pas être évitées via le mécanisme de verrouillage. Un niveau d'isolation des transactions sérialisées doit être utilisé, mais ce niveau d'isolation des transactions réduira considérablement la capacité de concurrence de la base de données. 🎜
🎜✔MySQL utilise le mécanisme MVCC (Multiple Version Concurrency Control) pour éviter les lectures non répétables et les lectures fantômes. 🎜

🎜4 Niveau d'isolement des transactions MySQL🎜

🎜Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL🎜🎜Utilisez la commande suivante pour interroger le niveau d'isolement des transactions au niveau global et au niveau de la session : 🎜
-- 事务A操作
START TRANSACTION;
SELECT * FROM account WHERE id = 1;     //在事务B提交之前执行
SELECT * FROM account WHERE id = 1;     //在事务B提交之后执行
COMMIT;
Copier après la connexion
Copier après la connexion
🎜< img src ="https://img.php.cn/upload/article/000/000/024/835fa42fc91ebf349593374d6a7a0896-6.png" alt="Une discussion approfondie sur les fonctionnalités de transaction et les principes de mise en œuvre dans MySQL" chargement="lazy"/>🎜

🎜5. Contrôle de concurrence multi-versions MVCC🎜

🎜Contrôle de concurrence multi-versionsContrôle de concurrence multi-versions, MVCC</code > est une méthode de contrôle de concurrence qui est généralement utilisée dans les systèmes de gestion de bases de données pour obtenir un accès simultané à la base de données. 🎜</blockquote><h3 data-id="heading-17">🎜Avantages de MVCC par rapport aux verrous🎜🎜🎜Vous pouvez considérer <code>MVCC comme un compromis de verrouillage au niveau des lignes, ce qui est utile dans de nombreux cas, cela évite l’utilisation de verrous et réduit les frais généraux. Selon l'implémentation, il peut autoriser des lectures non bloquantes, en verrouillant uniquement les enregistrements nécessaires pendant les écritures. 🎜

MVCC的实现原理

MVCC的是通过保存数据澡某个时间点的快照来实现的,也就是说,不管事务执行多长的时间,每个事务看到的数据都是一致的。根据事务的开始时间不同,每个事务对同一张表,同一时刻看到的数据可能是不一样的。InnonDB主要通过为每一行记录添加两个额外的隐藏的值来实现MVCC,这两个值一个记录这行数据何时被创建,另外一个记录这行数据何时过期(或者被删除)。但是InnoDB并不存储这些事件发生时的 实际时间 ,相反它只存储这些事件发生时的系统 版本号(version) 。这是一个随着事务的创建而不断增长的数字。每个事务在事务开始时会记录它自己的系统版本号。每个查询必须去检查每行数据的版本号与事务的版本号是否相同。

《高性能MySQL》书籍中介绍到:

MVCC只在REPEATABLE READREAD COMMITTIED两个隔离级别下工作,其他两个隔离级别都和MVCC不兼容,因为READ UNCOMMITTED总是读取最新的数据行,而不符合当前事务版本数据行,而SERIALIZABLE串行化隔离级别则会对所有读取的行都加锁。

接下来举个例子说明在可重复读事务隔离级别下,MVCC机制是如何完成增删改查操作的。

  • 查询操作(SELECT)

在查询操作中,InnoDB存储引擎跟根据以下两个条件查询对应的行记录,只有满足对应条件才会被返回:

1️⃣ 只查找不晚于当前事务版本的数据行,也就是说,InnoDB存储引擎只会查找版本号小于或者等于当前事务版本的数据行,这些数据行要么在该事务开始前就存在,要么就是事务本身插入或者更新的行。
2️⃣ 对于数据删除,数据行删除的版本要么还没有被定义,要么大于当前事务的版本号,只有这样才能确保事务读到的行,在事务开始前并没有被删除。

举个例子,存在 事务A事务B 两个事务,事务A中存在两套相同的SELECT语句,事务B存在一条UPDATE语句,事务A 的第一条查询语句在事务B提交之前执行,第二条查询语句在 事务B 提交之后执行,事务A 如下所示:

-- 事务A操作
START TRANSACTION;
SELECT * FROM account WHERE id = 1;     //在事务B提交之前执行
SELECT * FROM account WHERE id = 1;     //在事务B提交之后执行
COMMIT;
Copier après la connexion
Copier après la connexion

事务B:

-- 事务B操作
START TRANSACTION;
UPDATE account SET balance = balance+100 WHERE id = 1;
COMMIT;
Copier après la connexion

✔结论:如果没有使用MVCC机制,则事务A中的第一条SELECT语句读取的数据是修改前的数据,而第二条SELECT语句读取的是修改后的数据,两次读取的数据不一致,想想,那不就乱了吗?? 如果使用了MVCC机制,无论事务B如何修改数据,事务A的两条查询语句的到的结果始终是一致的。

  • 插入操作(SELECT)

在插入操作中,InnoDB会将新插入的每一条行记录的当前系统版本包保存为行版本号。

比如:向account表插入一条数据,同时MVCC的两个版本号分别为create_versiondelete_versioncreate_version代表创建行的版本号,delete_version代表删除行的版本号,另外还有一个事务ID字段,如下面所示:

INSERT INTO account(id, name, balance) values(1001, &#39;austin&#39;, 100);
Copier après la connexion

对应的版本号信息如下表:

idnamebalancetransaction_idcreate_versiondelete_version
1001austin10011未定义

可以看出,当向数据表新增记录时,需要设置保存行的版本号,而删除行的版本号未定义。

  • 更新操作(SELECT)

在更新操作中,InnoDB存储引擎会插入一行新记录,并保存当前系统的版本号为新记录行的版本号,同时保存当前系统的版本号到原来数据行作为删除标识。比如:将account数据表中id为1001的用户账户月增加100元,对应SQL如下:

UPDATE account SET balance = balance+100 WHERE id = 1001;
Copier après la connexion

执行SQL, 在MVCC机制下的更新操作如下表所示:

idnamebalancetransaction_idcreate_versiondelete_version
1001austin100112
1001austin20022未定义

可以明显看出,执行更新操作时,MVCC机制是先将原来的数据复制一份,将balance字段增加100后,再讲create_version字段的值设置为当前系统的版本号,而delete_version字段的值未定义。

注意的是:原来的行会被复制到Undo Log中。

  • 删除操作(SELECT)

在删除操作中,InnoDB存储引擎会保存删除的每一个行记录当前的系统版本号,作为删除标识。比如:删除account数据表中id为1001的数据,SQL如下所示:

DELETE FROM account WHERE id = 1001;
Copier après la connexion

对应MVCC机制下的删除操作如下表所示:

id name balance transaction_id create_version delete_version
1001 austin 200 3 2 3

可以看出,当删除数据表数据行时,MVCC机制会将当前系统的版本号写入删除数据行版本字段delete_version中,以此来表示当前数据行已经被删除。

六、总结

本文主要讲述了事务的特性、类型和本地事务和分布式事务的区别,通过不同的示例解释并发事务带来的更新丢失、脏读、不可重复读、幻读的问题,同时介绍了多版本并发控制MVCC的实现原理,如果文章对你有帮助,感谢点赞?+评论?+收藏❤,我是:?‍?austin流川枫,我们下期见!

【相关推荐:mysql视频教程

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Étiquettes associées:
source:juejin.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal