Maison >base de données >tutoriel mysql >Quels sont les niveaux d'isolement des transactions de base de données ?

Quels sont les niveaux d'isolement des transactions de base de données ?

青灯夜游
青灯夜游original
2021-05-24 15:05:1634365parcourir

Niveau d'isolement des transactions de base de données : 1. Lecture non validée ; 2. Lecture validée ; 3. Lecture répétable ;

Quels sont les niveaux d'isolement des transactions de base de données ?

L'environnement d'exploitation de ce tutoriel : système windows7, version mysql8, ordinateur Dell G3.

Dans les opérations de base de données, une transaction (Transaction) est une unité de travail indivisible composée d'une ou plusieurs instructions SQL qui font fonctionner la base de données. Ces opérations sont soit terminées, soit annulées.

Niveau d'isolement des transactions de base de données

Dans les applications réelles, les données de la base de données sont accessibles par plusieurs utilisateurs lorsque les utilisateurs utilisent les mêmes données. Dans le même temps, certains problèmes de simultanéité des transactions peuvent survenir, comme détaillé ci-dessous.

1) Lecture sale

signifie qu'une transaction lit les données non validées d'une autre transaction.

2) Lecture non répétable

signifie qu'une transaction lit deux fois la même ligne de données, mais les résultats sont différents.

3) Lecture virtuelle/lecture fantôme

signifie qu'une transaction exécute deux requêtes, mais que le résultat de la deuxième requête contient des données qui n'apparaissaient pas dans la première requête.

4) Mise à jour perdue

signifie que deux transactions mettent à jour une ligne de données en même temps, et la transaction soumise (ou révoquée) ultérieure écrase les données soumises par la transaction précédente.

Les mises à jour perdues peuvent être divisées en deux catégories, à savoir le premier type de mises à jour perdues et le deuxième type de mises à jour perdues.

  • Le premier type de mise à jour perdue fait référence au moment où deux transactions opèrent sur les mêmes données en même temps. Lorsque la première transaction est annulée, les données mises à jour de la deuxième transaction qui ont été mises à jour. soumis est écrasé, la deuxième transaction a entraîné une perte de données.

  • Le deuxième type de mise à jour perdue fait référence au cas où deux transactions opèrent sur les mêmes données en même temps. Une fois que la première transaction a soumis avec succès le résultat de la modification, la deuxième transaction a déjà validé le résultat. modification. Le résultat était un écrasement, entraînant une perte de données pour la deuxième transaction.

Afin d'éviter les problèmes de simultanéité des transactions ci-dessus, quatre niveaux d'isolation des transactions sont définis dans la spécification SQL standard. Différents niveaux d'isolation gèrent les transactions différemment. Les niveaux d'isolement de ces quatre transactions sont les suivants.

1) Lecture non validée (lecture non validée)

Pendant le processus d'exécution d'une transaction, il peut accéder à la fois aux données nouvellement insérées qui n'ont pas été validées par d'autres transactions et Données modifiées non validées. Si une transaction a commencé à écrire des données, une autre transaction n'est pas autorisée à écrire en même temps, mais d'autres transactions sont autorisées à lire cette ligne de données. Ce niveau d'isolement évite la perte de mises à jour.

2) Lecture validée

Pendant le processus d'exécution d'une transaction, il peut accéder à la fois aux données nouvellement insérées soumises avec succès par d'autres transactions et aux données modifiées avec succès. La transaction qui lit les données permet aux autres transactions de continuer à accéder à la ligne de données, mais la transaction d'écriture non validée empêchera les autres transactions d'accéder à la ligne. Ce niveau d’isolation empêche efficacement les lectures sales.

3) Lecture répétable (lecture répétable)

Pendant le processus d'exécution, une transaction peut accéder aux données nouvellement insérées soumises avec succès par d'autres transactions, mais elle ne peut pas accéder aux modifications réussies données. Les transactions qui lisent des données désactiveront les transactions d'écriture (mais autoriseront les transactions de lecture), et les transactions d'écriture désactiveront toutes les autres transactions. Ce niveau d'isolement empêche efficacement les lectures non répétables et les lectures sales.

4) Sérialisable (sérialisable)

Fournit une isolation stricte des transactions. Cela nécessite que les transactions soient exécutées en série, et les transactions ne peuvent être exécutées que les unes après les autres et ne peuvent pas être exécutées simultanément. Ce niveau d'isolement empêche efficacement les lectures incorrectes, les lectures non répétables et les lectures fantômes. Cependant, ce niveau peut conduire à un grand nombre de délais d'attente et de compétitions de verrouillage, et est rarement utilisé dans les applications pratiques.

De manière générale, plus le niveau d'isolement d'une transaction est élevé, plus elle peut garantir l'intégrité et la cohérence de la base de données. Cependant, relativement parlant, plus le niveau d'isolement est élevé, plus l'impact sur les performances de concurrence est important. Par conséquent, le niveau d'isolement de la base de données est généralement défini sur Read Comended, ce qui signifie la lecture des données validées, ce qui peut empêcher les lectures sales et offrir de meilleures performances de concurrence. Bien que ce niveau d'isolement puisse entraîner des problèmes de concurrence tels que des lectures non répétables, des lectures fantômes et des mises à jour perdues de type 2, ils peuvent être contrôlés en utilisant un verrouillage pessimiste et optimiste dans l'application.

Recommandations d'apprentissage gratuites associées : Tutoriel vidéo 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!

Déclaration:
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