Quels sont les niveaux d'isolement de MySQL ?

Il existe 4 niveaux d'isolement MySQL, à savoir : 1. Lecture non validée (lecture du contenu non validé) ; 2. Lecture validée (lecture du contenu soumis) 3. Lecture répétable (relisible) ;

(Tutoriel recommandé : Tutoriel mysql )

Les quatre niveaux d'isolement de Mysql

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

1. Lire non validé (lire le contenu non validé)

À ce niveau d'isolement, toutes les transactions peuvent voir les résultats d'exécution d'autres transactions non validé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.

2. Lecture validée (lire le contenu de la soumission)

Il s'agit du niveau d'isolement par défaut de 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 ce que l'on appelle la lecture 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.

3. Lecture répétable (lisible)

Il s'agit du niveau d'isolation des transactions par défaut de MySQL, qui garantit que lorsque plusieurs instances de la même transaction lisent des données simultanément, vous verra les mêmes lignes de données.

Mais en théorie, cela entraînera un autre problème épineux : 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 les lignes de données dans la plage, il constatera qu'il y a de nouveaux " Fantôme " OK. .

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).

4. Sérialisable (sérialisable)

Il s'agit du niveau d'isolement le plus élevé qui résout le problème magique en forçant l'ordre des transactions et en rendant impossible tout conflit entre elles. autre. Lisez la question. 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.

Problème

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 :

1. Lecture sale :

Une transaction a mis à jour une donnée et une autre transaction a lu la même donnée à ce moment-là, pour certaines raisons, si la précédente. L'opération RollBack est effectuée, les données lues par la transaction suivante seront incorrectes.

2. Lecture non répétable :

Les données sont incohérentes entre deux requêtes d'une transaction. Cela peut être dû au fait qu'une mise à jour de transaction a été insérée entre les deux requêtes d'origine.

3. 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 requête Cependant, la transaction est insérée. plusieurs nouvelles colonnes de données à ce moment-là. 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.

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!