Analysez brièvement les instantanés dans MVCC et voyez comment fonctionnent les instantanés ?

Cet article vous amènera à comprendre les instantanés dans MVCC et à voir comment fonctionnent les instantanés dans MVCC ? J'espère que cela pourra aider tout le monde !

MVCC

Dans MySQL (moteur de stockage innodb), en effet, chaque enregistrement enregistrera une opération de rollback en même temps qu'il sera mis à jour. La dernière valeur de l'enregistrement peut être obtenue en annulant la valeur de l'état précédent.

Supposons qu'une valeur soit modifiée de 1 à 2, 3 et 4 dans l'ordre, il y aura un enregistrement similaire au suivant dans le journal de restauration.

La valeur actuelle est 4, mais lors de l'interrogation de cet enregistrement, les transactions démarrées à des moments différents auront des vues de lecture différentes. Comme vous pouvez le voir sur la figure, dans les vues A, B et C, les valeurs de cet enregistrement sont respectivement 1, 2 et 4. Le même enregistrement peut exister dans plusieurs versions du système, ce qui est le multi-. contrôle de concurrence de versions (MVCC) de la base de données). Pour la vue en lecture A, pour obtenir 1, la valeur actuelle doit être obtenue en exécutant toutes les opérations de restauration de la figure.

Comment InnoDB définit-il un « instantané » ?

Chaque transaction dans InnoDB a un ID de transaction unique, appelé identifiant de transaction. Il est appliqué au système de transaction InnoDB au début de la transaction, et est strictement incrémentiel dans l'ordre d'application.

Et chaque ligne de données a également plusieurs versions. Chaque fois qu'une transaction met à jour les données, une nouvelle version des données sera générée et l'ID de transaction sera attribué à l'ID de transaction de cette version de données, enregistré sous la ligne trx_id. Dans le même temps, l'ancienne version des données doit être conservée et dans la nouvelle version des données, il doit y avoir des informations pouvant être obtenues directement.

En d'autres termes, une ligne d'enregistrements dans la table de données peut en fait avoir plusieurs versions (ligne), et chaque version a sa propre ligne trx_id.

Selon la définition de la lecture répétable, Lorsqu'une transaction est démarrée, tous les résultats de la transaction soumise peuvent être vus. Mais ensuite, pendant l’exécution de cette transaction, les mises à jour des autres transactions ne lui sont pas visibles.

Par conséquent, une transaction n'a besoin de déclarer qu'au démarrage : « En fonction du moment où je démarre, si une version de données est générée avant que je commence, elle sera reconnue ; si elle est générée après mon démarrage, je le ferai. Je ne le reconnais pas, je dois en retrouver la version précédente. Bien sûr, si la « version précédente » n’est pas non plus visible, il faut continuer à regarder vers l’avant. De plus, si les données sont mises à jour par la transaction elle-même, elle doit quand même les reconnaître.

En termes d'implémentation, InnoDB construit un tableau pour chaque transaction afin de sauvegarder tous les ID de transaction qui sont actuellement "actifs" au moment du démarrage de la transaction. « Actif » signifie qu'il a été démarré mais qu'il n'a pas encore été soumis.

La valeur minimale de l'ID de transaction dans le tableau est enregistrée comme niveau d'eau bas, et la valeur maximale de l'ID de transaction qui a été créé dans le système actuel plus 1 est enregistrée comme niveau d'eau haut.

Ce tableau de vues divise toutes les lignes trx_id en plusieurs situations différentes.

De cette façon, pour le moment de démarrage de la transaction en cours, la ligne trx_id d'une version de données a les possibilités suivantes :

• Si elle tombe dans la partie verte, cela signifie que cette version est une version soumise transaction ou la transaction actuelle La transaction elle-même génère ces données et ces données sont visibles

• Si elles tombent dans la partie rouge, cela signifie que cette version est générée par une transaction démarrée dans le futur et est définitivement invisible ;

  S'il tombe dans la partie jaune, alors il comprend deux situations
a. Si la ligne trx_id est dans le tableau, cela signifie que cette version est générée par une transaction qui n'a pas encore été soumise et est invisible

 ; b. Si la ligne trx_id n'est pas dans le tableau, cela signifie que cette version a été générée par la transaction validée et visible.

Par exemple :

la session A démarre une transaction A. Avant le début de la transaction A, il y a trois transactions actives dans le système et leurs identifiants sont 90 93 95.

Ensuite, l'ID de la transaction A est 100

À ce moment, le tableau de vues pour la transaction A est comme ceci [90 93 95 100], où le niveau d'eau bas est 90 et le niveau d'eau haut est 100+1=101 ; Maintenant, la transaction A commence à lire les données

• Si vous lisez que l'ID est 104, ce qui est supérieur à la limite supérieure de 101, cela signifie que cette version est générée par une transaction démarrée dans le futur, et elle est définitivement invisible
• Si vous lisez cela ; l'ID est 88, ce qui est inférieur au seuil bas de 90, cela signifie que cette version est une transaction soumise ou générée par la transaction en cours elle-même. Ces données sont visibles
• J'ai lu que l'ID est 94, ce qui est 94. se situe entre le niveau d'eau bas et le niveau d'eau haut, mais n'est pas dans le tableau [90 93 95 100]. Indique que cette version est générée par une transaction validée et est visible.
• J'ai lu que l'ID est 93, qui se situe entre le niveau d'eau bas et le niveau d'eau haut. Ce tableau [90 93 95 100] indique que cette version est générée par une transaction qui n'a pas encore été soumise et est invisible ;

Ceci Les règles de jugement sont directement traduites de la logique du code, mais comme vous pouvez le voir, il est difficile de les utiliser pour la visibilité de l'analyse de la chair humaine.

Alors, laissez-moi le traduire pour vous. Pour une version de données, pour une vue de transaction, en plus de ses propres mises à jour étant toujours visibles, il existe trois situations :

• la version n'est pas soumise et est invisible

• la version est soumise, mais elle est soumise après ; la vue est créée, invisible ;

• La version a été soumise, et elle a été soumise avant la création de la vue, elle est donc visible.

【Recommandations 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!