Les quatre niveaux d'isolation des transactions de MySQL

Tutoriel MySQLLa colonne présente quatre niveaux d'isolation des transactions

Recommandé (gratuit) : Tutoriel mysql

Environnement de test pour l'expérience de cet article : Windows 10+cmd+MySQL5.6.36+InnoDB

1. Éléments de base de la transaction (ACID)

　1. Atomicité : une fois la transaction démarrée, toutes les opérations sont soit terminées, soit ne rien faire. , et il est impossible de stagner au milieu. Si une erreur se produit lors de l'exécution de la transaction, elle sera restaurée à l'état avant le début de la transaction et toutes les opérations se dérouleront comme si elles ne s'étaient pas produites. C’est-à-dire que les choses forment un tout indivisible, tout comme les atomes appris en chimie, qui sont les unités de base de la matière.

　 2. Cohérence : Avant et après le début et la fin de la transaction, les contraintes d'intégrité de la base de données ne sont pas violées. Par exemple, si A transfère de l’argent à B, il est impossible pour A de déduire l’argent mais B de ne pas le recevoir.

3. Isolement : dans le même temps, une seule transaction est autorisée à demander les mêmes données, et il n'y a aucune interférence entre les différentes transactions. Par exemple, A retire de l'argent d'une carte bancaire. B ne peut pas transférer d'argent sur cette carte avant que le processus de retrait de A ne soit terminé.

4. Durabilité : une fois la transaction terminée, toutes les mises à jour de la base de données par la transaction seront enregistrées dans la base de données et ne pourront pas être annulées.

2. Problèmes de concurrence des transactions

1. Lecture sale : la transaction A lit les données mises à jour par la transaction B, puis B annule l'opération. , alors les données lues par A sont des données sales

2. Lecture non répétable : la transaction A lit les mêmes données plusieurs fois et la transaction B lit les mêmes données plusieurs fois dans la transaction A. , les données ont été mises à jour et soumises, ce qui a entraîné des résultats incohérents lorsque la transaction A a lu les mêmes données plusieurs fois.

3. Lecture fantôme : l'administrateur système A a modifié les notes de tous les élèves de la base de données des notes spécifiques aux notes ABCDE, mais l'administrateur système B a inséré une note spécifique à ce moment-là. L'administrateur système A a terminé la modification, il a constaté qu'il y avait encore un enregistrement qui n'avait pas été modifié. C'était comme s'il avait halluciné.

Résumé : La lecture non répétable et la lecture fantôme se confondent facilement. La lecture non répétable se concentre sur la modification, tandis que la lecture fantôme se concentre sur l'ajout ou la suppression. Pour résoudre le problème des lectures non répétables, il vous suffit de verrouiller les lignes qui remplissent les conditions. Pour résoudre le problème des lectures fantômes, vous devez verrouiller la table

3. Isolation des transactions MySQL. niveau

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

Le niveau d'isolement des transactions par défaut de MySQL est en lecture répétable

4. Utilisez des exemples pour illustrer chaque niveau d'isolement

1. Lire non validé :

(1) Ouvrez un client A et définissez le mode de transaction actuel pour lire non validé (lecture non validée), interrogez la valeur initiale du compte de table :

(2 ) Avant que la transaction du client A ne soit validée, ouvrez un autre client B et mettez à jour le compte de table :

(3) À ce moment, bien que le client B La transaction n'ait pas encore été soumise , mais le client A peut interroger les données mises à jour de B :

　(4) Une fois la transaction du client B annulée pour une raison quelconque, toutes les opérations seront annulées et les données interrogées par le client A sont en fait des données sales :

(5) Exécuter la déclaration de mise à jour du compte sur le client A définir le solde = solde - 50 où id = 1, le solde de lilei l'a fait ne devient pas 350, mais en fait 400. N'est-ce pas étrange ? Les données sont incohérentes. Si vous le pensez, vous êtes trop naïf dans l'application, nous utiliserons 400 -50=350, je ne sais pas que d'autres sessions. ont été annulés. Pour résoudre ce problème, vous pouvez utiliser le niveau d'isolement en lecture validée

2. En lecture validée

　(1) Ouvrir un client A, et définissez le mode de transaction actuel sur lecture validée (lecture validée), interrogez tous les enregistrements du compte de table :

　( 2) Avant que la transaction du client A ne soit soumise , ouvrez un autre client B et mettez à jour le compte de table :

　 (3) À ce moment, la transaction du client B n'est pas encore terminée Soumettre, le client A ne peut pas interroger le données mises à jour de B, résolvant le problème de lecture sale :

(4) Soumission de la transaction du client B

(5 ) Le client A exécute la même requête qu'à l'étape précédente, mais le résultat est incohérent avec l'étape précédente, ce qui provoque un problème de lecture non répétable

3. Lecture répétable

(1) Ouvrez un client A, définissez le mode de transaction actuel sur lecture répétable et interrogez tous les enregistrements du compte de table

　(2) Avant la transaction du client A est soumis, ouvrez un autre client B, mettez à jour le compte de table et soumettez

　(3) Interrogez la table sur le client A Tous les enregistrements du compte sont cohérents avec le la requête aboutit à l'étape (1), et il n'y a pas de problème de lecture non reproductible

　(4) Sur le client A, puis exécutez update balance = balance - 50 où id = 1, le solde ne devient pas 400-50 = 350, la valeur du solde de lilei est calculée en utilisant le 350 à l'étape (2), elle est donc 300, et la cohérence des données n'est pas détruite. Le mécanisme MVCC est utilisé sous le niveau d'isolement de lecture répétable. L'opération de sélection ne met pas à jour le numéro de version, mais est une lecture d'instantané (l'insertion, la mise à jour et la suppression mettront à jour le numéro de version et constituent une lecture actuelle (actuelle) ; version).

(5) Rouvrez le client B, insérez une nouvelle donnée et soumettez

(6) Dans le le client End A interroge tous les enregistrements de la table des comptes et aucune nouvelle donnée n'est trouvée, il n'y a donc pas de lecture fantôme

　4. Sérialisation

　(1 ) Ouvrez un client A, définissez le mode de transaction actuel sur sérialisable et interrogez la valeur initiale de la table des comptes :

(2) Ouvrez un client B et définissez le mode de transaction actuel sur sérialisable. Lors de l'insertion d'un enregistrement, une erreur est signalée et l'insertion échoue. Lorsque le niveau d'isolation des transactions dans MySQL est sérialisable, la table est signalée. sera verrouillé, donc les lectures fantômes ne se produiront pas. Dans ce cas, ce niveau d'isolement a une concurrence extrêmement faible et est rarement utilisé dans le développement.

　Supplément :

　1. Lorsque le niveau d'isolement des transactions est en lecture-validation, l'écriture des données ne verrouillera que la ligne correspondante

　2, lorsque le niveau d'isolement des transactions est en lecture répétable, si la condition de recherche a un index (y compris l'index de clé primaire), la méthode de verrouillage par défaut est le verrouillage par clé suivante si le condition de recherche Il n'y a pas d'index et la table entière sera verrouillée lors de la mise à jour des données. Un espace est verrouillé par une transaction et les autres transactions ne peuvent pas insérer d'enregistrements dans cet espace, empêchant ainsi les lectures fantômes.

3. Lorsque le niveau d'isolement des transactions est la sérialisation, la lecture et l'écriture des données verrouillent la table entière

4 Plus le niveau d'isolement est élevé, plus les données peuvent être complètes et cohérentes, mais plus l'impact sur les performances de concurrence est important.

5. Lien de référence du mécanisme de mise en œuvre de MYSQL MVCC : https://blog.csdn.net/whoamiyang/article/details/51901888

6. Concernant le verrouillage à clé suivante, veuillez vous référer au lien : https://blog.csdn.net/bigtree_3721/article/details/73731377

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!