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.
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 ! ! !
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.
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.
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 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.
Etgap 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隔离级别才存在间隙锁。
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 :
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!