Qu'est-ce que MVCC et pourquoi les verrous d'espacement sont-ils conçus ?

Cet article vous amènera à comprendre MVCC, à présenter la relation entre MVCC et le niveau d'isolement, du point de vue de la conception, à expliquer pourquoi MVCC est conçu et quelle est la différence entre les niveaux d'isolement de RC et RR.

Le rôle de MVCC

MVCC permet à la plupart des moteurs de transaction qui prennent en charge les verrous de ligne de ne plus simplement utiliser les verrous de ligne pour le contrôle de concurrence de la base de données. Au lieu de cela, combinez les verrous de ligne de la base de données avec les numéros de version de ligne. peut être réalisé avec très peu de frais généraux. Améliorant ainsi les performances de concurrence de la base de données.

MVCC résout le problème de conflit de lecture-écriture sans verrouillage. La lecture ici fait référence à l'instantané lu. C'est-à-dire la lecture d'instantanés implémentée par MVCC ! ! !

Qu'est-ce que MVCC

Le contrôle de concurrence multi-versions (MVCC) est un contrôle de concurrence sans verrouillage qui résout les conflits de lecture-écriture.

Chaque ligne d'enregistrements comporte deux colonnes masquées : le numéro de version de création et le pointeur de restauration. Il y a un identifiant de transaction après le démarrage de la transaction. Plusieurs transactions simultanées opèrent sur une certaine ligne en même temps. Les opérations de mise à jour de différentes transactions sur la ligne produiront plusieurs versions, puis utiliseront le pointeur d'annulation pour former une chaîne de journalisation d'annulation. La lecture de l'instantané de MVCC est réalisée via l'ID de transaction et le numéro de version de création.

La relation entre MVCC et le niveau d'isolement

MVCC est de résoudre le problème de lecture-écriture. Et grâce à différentes configurations, le problème de la lecture non répétable des instantanés après le démarrage de la transaction peut également être résolu.

• Lecture non répétable : certaines données lues dans la même transaction ont changé ou certains enregistrements ont été supprimés.

• Lecture fantôme : une transaction relit les données précédemment récupérées selon les mêmes conditions de requête, pour constater que d'autres transactions ont inséré de nouvelles données qui répondent aux conditions de requête. Ce phénomène est appelé lecture fantôme.

RC et RR implémentent MVCC, mais pourquoi RR résout-il le problème des lectures non répétables dans RC ?

Vous pouvez penser que la raison pour laquelle RC a le problème de lecture non répétable est simplement parce que les développeurs l'ont défini intentionnellement (en définissant plusieurs niveaux d'isolement, l'utilisateur peut le définir en fonction de la situation). À l'origine, les données ont été soumises à la base de données, il n'y a donc aucun problème lorsque RC les lit ? De plus, le niveau d'isolement de la base de données Oracle elle-même est RC.

READ-COMMITTED (Read ComMITTED)

Read Comended RC. Sous ce niveau d'isolement, une lecture cohérente peut être obtenue au niveau SQL, et chaque instruction SQL générera un nouveau ReadView. Cela signifie que d'autres transactions ont été soumises entre les deux requêtes et que des données incohérentes peuvent être lues.

REPEATABLE-READ (Lecture répétable)

Lecture répétable RR, après la première création du ReadView, ce ReadView sera maintenu jusqu'à la fin de la transaction, c'est-à-dire que la visibilité ne changera pas pendant l'exécution de la transaction, obtenant ainsi des lectures répétables au sein d'une transaction.

MVCC et gap lock

MVCC sans verrouillage résout le problème des conflits de lecture-écriture. Et résout le problème de lecture non reproductible. Cela permet d'obtenir deux niveaux d'isolement, RC et RR.

Et

gap lock est toujours essentiellement un verrou, qui bloquera l'exécution de deux transactions simultanées.

Alors pourquoi RR entre-t-il toujours dans le verrou d'espacement ? Est-ce juste pour résoudre le problème de la lecture fantôme ?

注意：只有RR隔离级别才存在间隙锁。

Gap Lock peut résoudre le problème de la lecture fantôme dans une certaine mesure, mais je pense que l'introduction du Gap Lock est davantage destinée à gérer les bugs dans le mode instruction de binlog.

La réplication maître-esclave de la base de données MySQL repose sur binlog. Avant mysql5.0, le mode binlog n'avait qu'un format d'instruction. Les caractéristiques de ce mode : l'ordre d'enregistrement du binlog est dans l'ordre de validation des transactions de la base de données.

Lorsqu'il n'y a pas de verrouillage d'espace, il y aura le scénario suivant : La bibliothèque principale a ces deux transactions :

1 Transaction a, supprimez l'identifiant 2. insère directement id=3 et termine la validation ;
3. La transaction a est validée ;
Le journal enregistré par le binlog à ce moment est : la transaction b est exécutée en premier et la transaction a est exécutée (le binlog enregistre l'ordre de validation)
Ensuite, la bibliothèque principale À ce moment, il y a un enregistrement avec id=3 dans la table, mais la base de données esclave est d'abord insérée puis supprimée, et il n'y a aucun enregistrement dans la base de données esclave.

Cela conduit à une incohérence entre les données maître et esclave.

Afin de résoudre ce bug, le verrouillage des écarts est introduit au niveau RR.

【Recommandation associée :

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!