Compréhension approfondie des 4 types de niveaux d'isolement dans MySQL

La norme SQL définit 4 types de niveaux d'isolement, y compris des règles spécifiques pour limiter les changements à l'intérieur et à l'extérieur de la transaction qui sont visibles et lesquels sont invisibles. Des niveaux d’isolation inférieurs prennent généralement en charge une concurrence plus élevée et entraînent une surcharge système inférieure.

Lire non validé (Lire le contenu non validé)

À ce niveau d'isolement, toutes les transactions peuvent être vues Les résultats d'exécution d'autres transactions non engagées. Ce niveau d'isolation est rarement utilisé dans les applications pratiques car ses performances ne sont guère meilleures que les autres niveaux. La lecture de données non validées est également appelée lecture sale.
Lecture validée

Il s'agit du niveau d'isolement par défaut pour la plupart des systèmes de bases de données (mais pas celui par défaut de MySQL). Cela répond à la définition simple de l'isolement : une transaction ne peut voir que les modifications apportées par les transactions validées. Ce niveau d'isolement prend également en charge la lecture dite non répétable, car d'autres instances de la même transaction peuvent avoir de nouvelles validations pendant le traitement de l'instance, de sorte que la même sélection peut renvoyer des résultats différents.
Lecture répétable (répétable)

Il s'agit du niveau d'isolation des transactions par défaut de MySQL, qui garantit que plusieurs instances de la même transaction peuvent lire les données simultanément. , vous verrez les mêmes lignes de données. Cependant, en théorie, cela entraînera un autre problème épineux : la lecture fantôme (Phantom Read). En termes simples, la lecture fantôme signifie que lorsque l'utilisateur lit une certaine plage de lignes de données, une autre transaction insère une nouvelle ligne dans la plage. Lorsque l'utilisateur lit à nouveau les lignes de données de la plage, il constatera qu'il y a de nouveaux " Fantôme ». D'ACCORD. Les moteurs de stockage InnoDB et Falcon résolvent ce problème grâce au mécanisme de contrôle de concurrence multiversion (MVCC, Multiversion Concurrency Control).

Sérialisable
Il s'agit du niveau d'isolement le plus élevé et est résolu en forçant les transactions à être ordonnées afin qu'elles ne puissent pas entrer en conflit les unes avec les autres. En bref, il ajoute un verrou partagé sur chaque ligne de données lue. À ce niveau, de nombreux délais d'attente et conflits de verrouillage peuvent en résulter.

Ces quatre niveaux d'isolement sont implémentés en utilisant différents types de verrous. Si les mêmes données sont lues, des problèmes peuvent facilement survenir. Par exemple :

Dirty Read : Une transaction a mis à jour une donnée et une autre transaction a lu les mêmes données à ce moment-là. Pour une raison quelconque, la précédente Si l'opération est RollBack. , les données lues par cette dernière transaction seront incorrectes.

Lecture non répétable : Les données sont incohérentes entre deux requêtes d'une transaction. Cela peut être dû aux données d'origine mises à jour par une transaction insérée entre les deux requêtes.

Lecture fantôme : le nombre d'éléments de données dans deux requêtes d'une transaction est incohérent. Par exemple, une transaction interroge plusieurs lignes de données, tandis qu'une autre transaction interroge à ce moment-là plusieurs nouvelles. Des colonnes de données sont insérées. Dans la requête ultérieure de la transaction précédente, vous constaterez qu'il existe plusieurs colonnes de données qu'elle n'avait pas auparavant.

Dans MySQL, ces quatre niveaux d'isolement sont implémentés, ce qui peut poser les problèmes suivants :

Ensuite, nous utiliserons le programme client MySQL pour tester plusieurs niveaux d'isolement. La base de données de test est test et la table est tx ; structure de la table :

num

Les deux clients en ligne de commande sont A et B ; ils changent constamment le niveau d'isolement de A et modifient les données du côté B.

(1) Définir le niveau d'isolement de A pour lire non validé (lecture non validée)

dans B Avant les données est mis à jour :

Client A :

Données mises à jour B :

Client B :

Client A :

Après l'expérience ci-dessus, nous pouvons conclure que la transaction B a mis à jour un enregistrement, mais qu'elle n'a pas été soumise. À ce stade, la transaction A peut interroger l'enregistrement non validé. Parce que des lectures sales. La lecture non validée est le niveau d'isolement le plus bas.

(2) Définir le niveau d'isolement des transactions du client A pour lire les commits

Avant que B n'ait mis à jour les données :

Client A :

B mettre à jour les données :

Client B :

Client A :

Après l'expérience ci-dessus, on peut conclure que le niveau d'isolement de lecture engagé résout le problème des lectures sales. Cependant, le problème de la lecture non répétable. se produit, c'est-à-dire que les données interrogées par la transaction A entre les deux requêtes sont incohérentes car la transaction B a mis à jour une donnée entre les deux requêtes. La lecture validée permet uniquement la lecture des enregistrements validés, mais ne nécessite pas de lectures répétables.

Réglez le niveau d'isolement de A sur lecture répétable (lecture répétable)

dans B avant les données sont mises à jour :

Client A :

B mise à jour des données :

Client B :

Client A :

B insère des données :

Client B :

Client A :

Sur la base de l'expérience ci-dessus, cela peut être a conclu que le niveau d'isolement de lecture répétable permet uniquement la lecture des enregistrements validés et que pendant la période où une transaction lit un enregistrement deux fois, d'autres transactions mettent à jour l'enregistrement. Mais il n’est pas nécessaire que la transaction soit sérialisable avec d’autres transactions. Par exemple, lorsqu'une transaction peut trouver des enregistrements mis à jour par une transaction validée, des problèmes de lecture fantôme peuvent survenir (notez que cela est possible car la base de données implémente les niveaux d'isolement différemment). Dans des expériences comme celle ci-dessus, il n’y a aucun problème de lecture fantôme des données.

(quatre), Réglez le niveau d'isolement de A sur Sérialisable

La face A ouvre la transaction et la face B insère un enregistrement

Transaction Face A :

Transaction côté B :

Parce que le niveau d'isolement de la transaction A est défini sur sérialisable à ce moment-là, après le démarrage de la transaction, elle n'est pas validée, donc la transaction B ne peut qu'attendre.

La transaction A valide la transaction :

Transaction A côté

Transaction côté B

Sérialisable verrouille complètement le champ Si une transaction interroge les mêmes données, elle doit attendre que la transaction précédente se termine et déverrouille le verrou . est un niveau d'isolement complet et verrouillera la table de données correspondante, il y aura donc des problèmes d'efficacité.

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!