Comment le niveau d'isolement de MySQL est-il implémenté ?

Méthode d'implémentation du niveau d'isolement mysql : lorsque le niveau d'isolement est une lecture non validée, toutes les lectures ne sont pas verrouillées, les données lues sont les dernières données, les performances sont les meilleures et toutes les écritures sont verrouillées au niveau de la ligne, libération après écriture. Lorsque le niveau d'isolement est la sérialisation, la lecture et l'écriture sont verrouillées.

Niveau d'isolement

(tutoriel recommandé : tutoriel mysql )

Il existe quatre niveaux d'isolement pour les transactions de base de données, de faible à élevé : lecture non validée, lecture validée, lecture répétable et sérialisable. Chaque niveau peut résoudre les problèmes de lectures sales, de lectures non répétables et de lectures fantômes un par un.

Mise en œuvre du niveau d'isolement :

Lecture non validée (RU : lecture-non validée) :

au niveau RU, toutes les données lues par la transaction sont les données les plus récentes, qui peuvent être des données après la soumission de la transaction, ou des données pendant l'exécution de la transaction (qui peuvent être annulées).

Lorsque le niveau d'isolement est RU :

• Toutes les lectures ne sont pas verrouillées et les données lues sont les données les plus récentes, avec les meilleures performances.

• Ajoutez des verrous au niveau des lignes à toutes les écritures et libérez-les après l'écriture.

Lecture-commise (RC : lecture-commise) :

Utiliser la technologie MVCC pour ajouter des champs masqués à chaque ligne (DB_TRX_ID : modifier le L'identifiant de la dernière transaction de la ligne, DB_ROLL_PTR : pointe vers le journal d'annulation de la ligne actuelle, DB_ROW_ID : identifiant de ligne, DELETE_BIT : indicateur de suppression), qui implémente les opérations de lecture déverrouillées.

Lorsque le niveau d'isolement est RC :

• Opération d'écriture : ajouter un verrouillage au niveau de la ligne. Une fois la transaction démarrée, un enregistrement de modification est écrit dans le journal UNDO et la colonne masquée DATA_POLL_PTR dans la ligne de données stocke un pointeur vers l'enregistrement UNDO de la ligne.

• Opération lecture : Pas de verrouillage. Lors de la lecture, si la ligne est verrouillée par d'autres transactions, suivez le pointeur de la colonne cachée DATA_POLL_PTR pour retrouver l'enregistrement historique valide précédent (enregistrement valide : cet enregistrement est visible par la transaction en cours, et DELETE_BIT=0).

Lecture répétable (RR : lecture répétable) :

Utilisez la technologie MVCC pour implémenter des opérations de lecture sans verrouillage.

Lorsque le niveau d'isolement est RR :

• Opération d'écriture : ajouter un verrouillage au niveau de la ligne. Une fois la transaction démarrée, un enregistrement de modification est écrit dans le journal UNDO et la colonne masquée DATA_POLL_PTR dans la ligne de données stocke un pointeur vers l'enregistrement UNDO de la ligne.

• Opération lecture : Pas de verrouillage. Lors de la lecture, si la ligne est verrouillée par d'autres transactions, suivez le pointeur de la colonne cachée DATA_POLL_PTR pour retrouver l'enregistrement historique valide précédent (enregistrement valide : cet enregistrement est visible par la transaction en cours, et DELETE_BIT=0).

Comme vous pouvez le savoir d'après ce qui précède : En fait, les opérations aux niveaux RC et RR sont fondamentalement les mêmes, mais la différence réside dans : la visibilité de l'enregistrement du rang pour le transaction en cours (visibilité : c'est-à-dire quels enregistrements de ligne de version sont visibles pour cette transaction). La visibilité des données au niveau RC est le dernier enregistrement des données, et la visibilité de base des données RR est l'enregistrement des données au début de la transaction.

(1) Implémentation de la visibilité des enregistrements de lignes (read_view)

Dans innodb, lors de la création d'une transaction, la liste des transactions actives dans le système actuel sera Créer un copie (read_view), qui stocke les transactions qui n'ont pas encore été validées au début de la transaction en cours. Les valeurs de ces transactions ne sont pas visibles pour la transaction en cours.

Il y a deux valeurs clés​​up_limit_id dans read_view (le numéro de version minimum de la transaction non validée actuelle est -1, les transactions avant up_limit_id ont été soumises, les transactions après up_limit_id peuvent être soumises, ne peuvent pas être soumises ) et low_limit_id (L'ID de transaction suivant qui n'a pas encore été attribué par le système actuel est la valeur maximale des ID de transaction qui ont eu lieu jusqu'à présent + 1. Remarque : low_limit_id n'est pas l'ID de la plus grande transaction active.)

Remarque : actuellement, la transaction et la transaction en cours de validation ne sont pas dans read_view.

(2) Qu'il s'agisse de niveau RC ou de niveau RR, la logique pour juger de la visibilité des enregistrements de lignes est la même.

Lorsque la transaction lit l'enregistrement de ligne en annulation, le numéro de version (DB_TRX_ID) de l'enregistrement de ligne sera comparé à read_view :

1 Si DB_TRX_ID est inférieur à up_limit_id, cela signifie que. la ligne L'enregistrement a été validé avant le début de la transaction en cours et DELETE_BIT=0, alors l'enregistrement de ligne est visible pour la transaction en cours.

2. Si DB_TRX_ID est supérieur à low_limit_id, cela signifie que la transaction dans laquelle la ligne est enregistrée a été démarrée après la création de cette transaction, donc la valeur actuelle de l'enregistrement de la ligne n'est pas visible.

3. Si up_limit_id< = DB_TRX_ID <= low_limit_id, déterminez si DB_TRX_ID est dans la chaîne de transaction active. Si c'est le cas, il est invisible.

4. Si les jugements ci-dessus sont invisibles, lisez l'enregistrement de la ligne précédente de la ligne en annulation et continuez à juger.

La différence entre les instantanés au niveau de l'instruction au niveau RC et les instantanés au niveau des transactions au niveau RR est en fait réalisée par le timing de génération read_view.

Lors de l'exécution d'une instruction, le niveau RC fermera d'abord la read_view d'origine et régénérera une nouvelle read_view. Le read_view au niveau RR n’est créé qu’au début de la transaction. Par conséquent, le niveau RU obtient les données les plus récentes à chaque fois, tandis que le niveau RR obtient les données au début de la transaction.

(3) Il convient de noter : Dans le jugement de visibilité ci-dessus, bien que la logique soit la même, il existe des différences dans la signification pratique :

dans Dans le second étape, pour le niveau RC, low_limit_id est l'identifiant de transaction maximum + 1 qui s'est produit lors de l'exécution de l'instruction. On peut considérer que lorsque l'instruction est exécutée, il n'y a pas de transaction supérieure à low_limit_id, donc les transactions supérieures à low_limit_id ne le sont pas. Visible.

Pour le niveau RR, low_limit_id est la plus grande transaction survenue au début de la transaction en cours + 1 (elle peut également être considérée comme l'identifiant de la transaction en cours + 1, car lorsque la transaction en cours est créée, l'identifiant de la transaction en cours est le plus grand), les transactions supérieures à low_limit_id sont créées après le démarrage de la transaction, elles ne sont donc pas visibles au niveau RR.

Dans la troisième étape, pour le niveau RC, tant que DB_TRX_ID n'est pas dans la liste chaînée active, RC est visible, que DB_TRX_ID soit supérieur ou non à l'identifiant de la transaction.

Pour le niveau RR, comme low_limit_id est l'identifiant de la transaction actuelle + 1, on peut considérer que les transactions inférieures à low_limit_id apparaissent avant la création de la transaction actuelle, il vous suffit donc de juger simplement si DB_TRX_ID est dans le liste chaînée active.

Sérialisable : la lecture et l'écriture sont verrouillées

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!