Quels sont les points de connaissance du contrôle de concurrence multi-version Mysql MVCC ?

1, MVCC

Le contrôle de concurrence multi-versions (MVCC) fait référence à.... MVCC est une méthode de contrôle de concurrence. Elle est généralement utilisée dans les systèmes de gestion de bases de données pour obtenir un accès simultané à la base de données et pour implémenter la mémoire transactionnelle dans les langages de programmation.

L'implémentation de MVCC dans MySQL InnoDB vise principalement à améliorer les performances de concurrence des bases de données et à utiliser une meilleure façon de gérer les conflits de lecture et d'écriture, de sorte que même s'il y a > des conflits de lecture et d'écriture, Il ne peut réaliser aucune lecture simultanée verrouillable et non bloquante.

2. Lecture en cours

Opérations comme sélectionner le verrouillage en mode partage (verrouillage partagé), sélectionner pour la mise à jour, insérer, supprimer (verrouillage exclusif) C'est c'est une sorte de lecture actuelle. Pourquoi s'appelle-t-on lecture actuelle ? Autrement dit, il lit la dernière version de l'enregistrement lors de la lecture, il doit également s'assurer que d'autres transactions simultanées ne peuvent pas modifier l'enregistrement actuel et que l'enregistrement lu sera verrouillé.

3. La lecture d'instantanés (améliore la capacité de requête simultanée de la base de données)

L'opération de sélection sans verrouillage est une lecture d'instantané, c'est-à-dire une lecture non bloquante sans verrouillage de la lecture d'instantané ; Le principe est que le niveau d'isolement n'est pas le niveau série et que les lectures d'instantanés au niveau série dégénéreront en lectures actuelles ; la raison pour laquelle les lectures d'instantanés se produisent est basée sur la prise en compte de l'amélioration des performances de concurrence, et la mise en œuvre des lectures d'instantanés est basée sur sur le contrôle de concurrence multi-versions. Autrement dit, MVCC peut être considéré comme une variante du verrouillage de ligne, mais dans de nombreux cas, il évite les opérations de verrouillage et réduit la surcharge car il est basé sur plusieurs versions, ce que l'instantané lu peut lire ne l'est pas ; nécessairement la dernière version des données, qui peut être la version historique précédente

4, lecture actuelle, lecture d'instantané, relation MVCC

Le contrôle de concurrence multi-versions MVCC fait référence au maintien de plusieurs. versions d'une version de données, afin qu'il n'y ait pas de conflit dans les opérations de lecture et d'écriture. La lecture d'instantanés est une fonction de lecture non bloquante de MySQL pour implémenter MVCC. L'implémentation spécifique du module MVCC dans MySQL est implémentée par trois champs implicites, undo log et read view.

5. Principe d'implémentation de MVCC

Le principe d'implémentation de mvcc repose principalement sur les trois champs cachés dans la vue d'enregistrement, d'annulation et de lecture.

Champs cachés

En plus de nos champs personnalisés, les enregistrements de ligne ont également DB_TRX_ID, DB_ROLL_PTR, DB_ROW_ID et d'autres champs implicitement définis par la base de données .

DB_TRX_ID

6 octets, l'identifiant de transaction le plus récemment modifié, enregistre l'identifiant de transaction qui a créé cet enregistrement ou l'a modifié pour la dernière fois#. 🎜 🎜#

DB_ROLL_PTR

7 octets, pointeur de restauration, pointant vers la version précédente de cet enregistrement, utilisé pour coopérer avec undolog, pointant vers l'ancienne version précédente version

DB_ROW_JD

6 octets, clé primaire cachée, si la table de données n'a pas de clé primaire, alors innodb générera automatiquement un Le row_id

row_id

undo log

undolog被称之为回滚日志，表示在进行insert，delete，update操作的时候产生的方便回滚的日志 当进行insert操作的时候，产生的undolog只在事务回滚的时候需要，并且在事务提交之后可以被立刻丢弃 当进行update和delete操作的时候，产生的undolog不仅仅在事务回滚的时候需要，在快照读的时候也需要，所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除（当数据发生更新和删除操作的时候都只是设置一下老记录的deleted_bit，并不是真正的将过时的记录删除，因为为了节省磁盘空间，innodb有专门的purge线程来清除deleted_bit为true的记录，如果某个记录的deleted_id为true

undo log

undolog de 6 octets est appelé un journal de restauration, indiquant que l'insertion, la suppression, et la mise à jour sont en cours. Journaux générés pendant les opérations pour faciliter la restauration. Lorsque les opérations d'insertion sont effectuées, l'annulation de journalisation générée n'est nécessaire que lorsque la transaction est annulée et peut être supprimée immédiatement après la validation de la transaction. Lorsque les opérations de mise à jour et de suppression sont effectuées. , l'undolog généré est non seulement nécessaire lorsque la transaction est annulée, mais également lorsque l'instantané est lu, il ne peut donc pas être supprimé par hasard. Ce n'est que lorsque la lecture de l'instantané ou l'annulation de la transaction n'implique pas le journal que le journal correspondant sera généré. être uniformément effacé par le thread de purge (lorsque les données Lorsqu'une opération de mise à jour ou de suppression se produit, il définit uniquement le delete_bit de l'ancien enregistrement. Il ne supprime pas réellement l'enregistrement obsolète, car afin d'économiser de l'espace disque, innodb a un spécial purger le thread pour effacer l'enregistrement deleted_bit en true, si le deleted_id d'un enregistrement est vrai et que le DB_TRX_ID est visible par rapport à la vue en lecture du thread de purge, alors cet enregistrement peut être effacé de temps en temps)

# 🎜🎜#Read View

Read View est une vue en lecture produite lorsqu'une transaction effectue une opération de lecture instantanée. Au moment où la transaction effectue une lecture d'instantané, un instantané actuel du système de données sera généré, enregistrera et conservera l'ID de la transaction actuellement active dans le système, et la valeur de l'ID de la transaction augmentera.

6. L'idée centrale de MVCC

L'idée centrale de MVCC est : Je peux vérifier les données qui existaient auparavant ma transaction a démarré, même si elle est modifiée ou supprimée ultérieurement. Je ne trouve pas les données nouvellement ajoutées après ma transaction.

Règles de recherche MVCC : Peut uniquement rechercher les données dont l'heure de création est inférieure ou égale à l'ID de transaction actuel et les lignes dont l'heure de suppression est supérieure à l'ID de transaction actuelle ( ou non supprimé)

Comme le montre l'image, deux éléments de données sont insérés dans la transaction Transaction1, et la transaction est soumise, puis lue dans la transaction Transaction2, et deux données sont lues

#🎜🎜##🎜🎜#Comme le montre l'image, insérez une donnée pour l'ancienne connexion dans la Transaction3 transaction, puis lisez-la dans la transaction Transaction2. Selon les règles mvcc, le début de ma transaction est introuvable. Après avoir inséré les données insérées, l'ID de création de Laolian est supérieur à 2, donc seules deux données peuvent être trouvées. #🎜🎜#

Comme le montre l'image, les données avec l'identifiant 2 sont supprimées dans la transaction Transaction4, puis lues dans la transaction Transaction2. Selon les règles mvcc, les données insérées et supprimées après le début de ma transaction peuvent être retrouvées. . Lao Chao peut encore le découvrir, alors j'ai toujours trouvé deux données

Comme le montre la figure, dans la transaction Transaction5, ajoutez une donnée avec name=Brother Tao, supprimez les données avec id=1. , modifiez l'identifiant de name=Brother Tao en 1, puis lisez-le dans Transaction2. Selon les règles mvcc, les données insérées et supprimées après le début de ma transaction peuvent toujours être trouvées, donc deux éléments de données. sont toujours trouvés

Grâce à la démonstration ci-dessus, nous pouvons voir que grâce au contrôle du numéro de version, que d'autres transactions soient insérées, modifiées ou supprimées, les données interrogées par Transaction2 n'ont pas changé.

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!