[MySQL] Contrôle de concurrence multiversion

L'implémentation de la plupart des moteurs de stockage transactionnels dans MySQL n'est pas un simple verrou au niveau des lignes. Basés sur l'amélioration des performances de concurrence, ils implémentent généralement le contrôle de concurrence multiversion (MVCC) en même temps. Non seulement MySQL, mais d'autres systèmes de bases de données tels qu'Oracle et PostgreSQL implémentent également MVCC, mais leurs mécanismes d'implémentation sont différents car il n'existe pas de norme unifiée pour MVCC.

Vous pouvez considérer MVCC comme une variante du verrouillage au niveau des lignes, mais il évite les opérations de verrouillage dans de nombreux cas, donc la surcharge est moindre. Bien que les mécanismes d'implémentation soient différents, la plupart d'entre eux implémentent des opérations de lecture non bloquantes et les opérations d'écriture ne verrouillent que les lignes nécessaires.

MVCC est implémenté en enregistrant un instantané des données à un moment donné. En d’autres termes, quel que soit le temps d’exécution, les données vues par chaque transaction sont cohérentes. Selon l'heure à laquelle la transaction démarre, les données vues par chaque transaction sur la même table au même moment peuvent être différentes.

L'implémentation MVCC des différents moteurs de stockage est différente, généralement un contrôle de concurrence optimiste et un contrôle de concurrence pessimiste. Ci-dessous, nous illustrons le fonctionnement de MVCC à travers une version simplifiée du comportement d'InnoDB.

Le MVCC d'InnoDB est implémenté en enregistrant deux colonnes cachées derrière chaque ligne d'enregistrements. Parmi ces deux colonnes, l’une contient l’heure de création de la ligne et l’autre l’heure d’expiration (ou l’heure de suppression) de la ligne. Bien entendu, ce qui est stocké n’est pas la valeur temporelle réelle, mais le numéro de version du système. Chaque fois qu'une nouvelle transaction est démarrée, le numéro de version du système est automatiquement incrémenté. affaires. Le numéro de version du système au début de la transaction sera utilisé comme numéro de version de la transaction, qui est utilisé pour comparer avec le numéro de version de chaque ligne d'enregistrements interrogés. Jetons un coup d'œil au fonctionnement de MVCC sous le niveau d'isolement REPEATABLE READ.

SELECT

InnoDB vérifiera chaque ligne d'enregistrements en fonction des deux conditions suivantes :

• InnoDB recherche uniquement les lignes de données dont le numéro de version est antérieur que la version actuelle de la transaction (c'est-à-dire que le numéro de version du système de la ligne est inférieur ou égal à la transaction). Cela garantit que les lignes lues par la transaction existent déjà avant le début de la transaction ou ont été insérées ou modifiées par. la transaction elle-même. La version supprimée de la ligne

• est soit indéfinie, soit supérieure au numéro de version actuel de la transaction. Cela garantit que les lignes lues par la transaction n'ont pas été supprimées avant le démarrage de la transaction.

Seuls les enregistrements qui remplissent les deux conditions ci-dessus peuvent être renvoyés en tant que résultats de requête.

INSERT

InnoDB enregistre le numéro de version actuel du système en tant que numéro de version de ligne pour chaque ligne insérée.

DELETE

InnoDB enregistre le numéro de version actuel du système comme identifiant de suppression de ligne pour chaque ligne supprimée.

UPDATE

InnoDB insère une nouvelle ligne d'enregistrements, enregistre le numéro de version actuel du système en tant que numéro de version de la ligne et enregistre le numéro de version actuel du système dans la ligne d'origine en tant qu'identifiant de suppression de ligne.

Enregistrez ces deux numéros de version supplémentaires du système afin que la plupart des opérations de lecture de données puissent être effectuées sans verrouillage. Cette conception rend l'opération de lecture des données très simple, les performances sont très bonnes et garantit également que seules les lignes répondant aux normes sont lues. Les inconvénients sont que chaque ligne d'enregistrements nécessite un espace de stockage supplémentaire, davantage de vérifications et une maintenance supplémentaire.

MVCC ne fonctionne que sous deux niveaux d'isolement : REPEATABLE READ et READ COMMITTED. Les deux autres niveaux d'isolement sont incompatibles avec MVCC car READ UNCOMMITTED lit toujours la dernière ligne de données, et non la ligne de données conforme à la version actuelle de la transaction. SERIALIZABLE verrouillera toutes les lignes lues.

Remarque : MVCC n'a pas de spécification formelle, donc l'implémentation de chaque moteur de stockage et système de base de données est différente. Personne ne peut dire que les autres méthodes sont fausses.

L'implémentation de la plupart des moteurs de stockage transactionnels dans MySQL n'est pas un simple verrou au niveau des lignes. Basés sur l'amélioration des performances de concurrence, ils implémentent généralement le contrôle de concurrence multiversion (MVCC) en même temps. Non seulement MySQL, mais d'autres systèmes de bases de données tels qu'Oracle et PostgreSQL implémentent également MVCC, mais leurs mécanismes d'implémentation sont différents car il n'existe pas de norme unifiée pour MVCC.

Vous pouvez considérer MVCC comme une variante du verrouillage au niveau des lignes, mais il évite les opérations de verrouillage dans de nombreux cas, donc la surcharge est moindre. Bien que les mécanismes d'implémentation soient différents, la plupart d'entre eux implémentent des opérations de lecture non bloquantes et les opérations d'écriture ne verrouillent que les lignes nécessaires.

MVCC est implémenté en enregistrant un instantané des données à un moment donné. En d’autres termes, quel que soit le temps d’exécution, les données vues par chaque transaction sont cohérentes. Selon l'heure à laquelle la transaction démarre, les données vues par chaque transaction sur la même table au même moment peuvent être différentes.

L'implémentation MVCC des différents moteurs de stockage est différente, généralement un contrôle de concurrence optimiste et un contrôle de concurrence pessimiste. Ci-dessous, nous illustrons le fonctionnement de MVCC à travers une version simplifiée du comportement d'InnoDB.

Le MVCC d'InnoDB est implémenté en enregistrant deux colonnes cachées derrière chaque ligne d'enregistrements. Parmi ces deux colonnes, l’une contient l’heure de création de la ligne et l’autre l’heure d’expiration (ou l’heure de suppression) de la ligne. Bien entendu, ce qui est stocké n’est pas la valeur temporelle réelle, mais le numéro de version du système. Chaque fois qu'une nouvelle transaction est démarrée, le numéro de version du système est automatiquement incrémenté. affaires. Le numéro de version du système au début de la transaction sera utilisé comme numéro de version de la transaction, qui est utilisé pour comparer avec le numéro de version de chaque ligne d'enregistrements interrogés. Jetons un coup d'œil au fonctionnement de MVCC sous le niveau d'isolement REPEATABLE READ.

SELECT

InnoDB vérifiera chaque ligne d'enregistrements en fonction des deux conditions suivantes :

• InnoDB recherche uniquement les lignes de données dont le numéro de version est antérieur que la version actuelle de la transaction (c'est-à-dire que le numéro de version du système de la ligne est inférieur ou égal à la transaction). Cela garantit que les lignes lues par la transaction existent déjà avant le début de la transaction ou ont été insérées ou modifiées par. la transaction elle-même. La version supprimée de la ligne

• est soit indéfinie, soit supérieure au numéro de version actuel de la transaction. Cela garantit que les lignes lues par la transaction n'ont pas été supprimées avant le démarrage de la transaction.

Seuls les enregistrements qui remplissent les deux conditions ci-dessus peuvent être renvoyés en tant que résultats de requête.

INSERT

InnoDB enregistre le numéro de version actuel du système en tant que numéro de version de ligne pour chaque ligne insérée.

DELETE

InnoDB enregistre le numéro de version actuel du système comme identifiant de suppression de ligne pour chaque ligne supprimée.

UPDATE

InnoDB insère une nouvelle ligne d'enregistrements, enregistre le numéro de version actuel du système en tant que numéro de version de la ligne et enregistre le numéro de version actuel du système dans la ligne d'origine en tant qu'identifiant de suppression de ligne.

Enregistrez ces deux numéros de version supplémentaires du système afin que la plupart des opérations de lecture de données puissent être effectuées sans verrouillage. Cette conception rend l'opération de lecture des données très simple, les performances sont très bonnes et garantit également que seules les lignes répondant aux normes sont lues. Les inconvénients sont que chaque ligne d'enregistrements nécessite un espace de stockage supplémentaire, davantage de vérifications et une maintenance supplémentaire.

MVCC ne fonctionne que sous deux niveaux d'isolement : REPEATABLE READ et READ COMMITTED. Les deux autres niveaux d'isolement sont incompatibles avec MVCC car READ UNCOMMITTED lit toujours la dernière ligne de données, et non la ligne de données conforme à la version actuelle de la transaction. SERIALIZABLE verrouillera toutes les lignes lues.

Remarque : MVCC n'a pas de spécification formelle, donc l'implémentation de chaque moteur de stockage et système de base de données est différente. Personne ne peut dire que les autres méthodes sont fausses.

Ce qui précède est le contenu du contrôle de concurrence multi-version [MySQL] Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !