Le mécanisme des transactions de base de données MySQL [Résumé]

Ces derniers jours, lors d'entretiens, j'ai été interrogé à plusieurs reprises sur les mécanismes de transaction des bases de données, les niveaux d'isolement, les verrous optimistes et les verrous pessimistes. Je peux seulement dire que j'en avais encore une certaine compréhension auparavant. niveau de mémoire et je ne les comprends pas, alors j'ai répondu Pas bon. J'ai lu le livre plus tard pour étudier et comprendre certaines choses, je vais donc en faire un enregistrement ici.

Qu'est-ce qu'une transaction ?

Ce que j'entends par transaction est un comportement commercial complet. Un comportement commercial peut contenir plusieurs actions. Cette action complète constitue une transaction. Un exemple plus classique est celui d'un virement bancaire. Le transfert du compte A vers le compte B nécessite deux actions : soustraire du compte A et ajouter au compte B. Il faut s'assurer que ces deux actions sont effectuées, sinon aucune n'est effectuée.

Les transactions ont des caractéristiques ACID, notamment :

● Atomicité (atomicité) : l'atomicité signifie que les transactions sont indivisibles, soit toutes réussies, soit toutes échouées, non partiellement réussies et partiellement échouées. En cas d'échec à mi-chemin, le champ de bataille doit être nettoyé, c'est-à-dire que les données sont restaurées.

● Cohérence : la cohérence fait référence au résultat final d'une transaction, garantissant qu'il n'y a pas d'anomalies dans les données. La cohérence met l'accent sur les résultats et est basée sur l'atomicité. Autrement dit, si l'atomicité peut être garantie, il y aura des résultats cohérents.

● Isolement : l'isolement signifie qu'une transaction n'est pas visible par les autres transactions avant d'être soumise, et que les données entre les transactions sont isolées (bien sûr, le degré d'isolement est différent selon les niveaux).

● Durabilité : une fois la transaction soumise, elle sera persistante et pourra être enregistrée pendant une longue période.

Niveau d'isolement des transactions

Avant de comprendre le niveau d'isolement d'une transaction, vous devez comprendre plusieurs concepts de lecture de données :

● Lecture sale : cela signifie lire des données que d'autres n'ont pas encore soumises.

● Lecture répétable : il s'agit de deux requêtes dans la même chose. Si quelqu'un d'autre modifie l'enregistrement dans la requête et le soumet, il ne sera pas visible pour la deuxième requête et le même enregistrement n'apparaîtra pas. deux requêtes sont incohérentes.

● Lecture fantôme : il s'agit de deux requêtes dans une seule chose. Si quelqu'un d'autre ajoute un enregistrement et le soumet au milieu, ce qui peut être trouvé dans la deuxième requête sera incohérent avec le premier enregistrement.

Le contrôle des transactions est divisé en plusieurs niveaux. Le niveau détermine le degré d'isolement. Il existe quatre niveaux dans MySQL :

● Lire non validé : ce niveau est Au niveau. Au niveau le plus bas, si la modification de la transaction A n'est pas validée, elle sera visible par la transaction B et une lecture sale des données se produira. Ce type n'est généralement pas utilisé.

● Lecture soumise : La modification de la chose A n'est visible par B qu'après sa soumission. Dans ce cas, il y aura un problème de lecture fantôme des données, et les résultats des deux requêtes seront différents. .

● Lecture répétable : c'est le niveau par défaut de MySQL. Entre deux requêtes à ce niveau, un certain enregistrement est modifié au milieu, ce qui est invisible pour les autres transactions, garantissant que les requêtes répétées sont cohérentes. , mais d'autres transactions sont visibles pour les nouveaux ajouts, donc de nouvelles lectures fantômes se produiront toujours.

● Sérialisable : les transactions sont exécutées en série et chaque enregistrement interrogé est verrouillé. Un blocage se produira et la concurrence entraînera de graves problèmes de performances, donc généralement ce type ne sera pas utilisé.

Aperçu du niveau d'isolement

Mise en œuvre de l'isolement des transactions

L'isolement des transactions est contrôlé de deux manières : l'une est la méthode de verrouillage, qui réalise l'isolement par séparation temporelle ; l'autre est la méthode de contrôle de version, qui enregistre plusieurs versions pour obtenir l'isolement.

1. Verrous

Les verrous dans MySQL sont divisés en verrous de lecture et verrous d'écriture. Étant donné que les verrous de lecture lisent les données, plusieurs lectures des mêmes données peuvent être effectuées. en même temps, il a une nature partagée ; le verrou en écriture implique des modifications de données, il entre donc en conflit avec d'autres verrous en écriture et en lecture et a un caractère exclusif.

En termes de granularité des verrous, il est divisé en verrous au niveau de la table et en verrous au niveau des lignes. Les verrous de table se produisent généralement lorsque la structure de la table est modifiée ou que la table entière est mise à jour, et bloquent toutes les lectures et écritures. les opérations sur cette table ; les verrouillages au niveau des lignes se produisent généralement lorsqu'un enregistrement spécifié est mis à jour, et seul l'enregistrement spécifié sera verrouillé. Plus la granularité du verrouillage est petite, plus la concurrence est élevée. Les verrous au niveau des lignes doivent être prioritaires et les verrous de table doivent être évités autant que possible. C'est le même principe que la granularité du verrouillage dans le programme.

2. Contrôle de concurrence multi-versions

Pour des raisons de performances, MySQL dispose d'une autre méthode en plus du verrouillage au niveau des lignes, le contrôle de concurrence multi-version, qui est contrôlé par le stockage. Implémentation du moteur.

Le livre explique une méthode d'implémentation simple d'InnoDB. Cette méthode utilise un enregistrement avec plusieurs versions. Deux colonnes masquées sont ajoutées à chaque enregistrement, l'une est le numéro de version de création et l'autre est la suppression du numéro de version. Chaque fois qu'une transaction est ouverte, un numéro de version de transaction sera attribué. Le numéro de version de transaction est incrémenté et les opérations au sein de la transaction seront comparées en fonction de ce numéro de version. Les détails sont les suivants :

Numéro de version actuel)

● Lors de l'insertion : Le numéro de version de création enregistré est le numéro de version actuelle de la transaction.

● Lors de la suppression : Le numéro de version supprimé de l'enregistrement de mise à jour est le numéro de version actuelle de la transaction.

● Lors de la mise à jour : insérez un nouvel enregistrement, le numéro de version de création est le numéro de version actuel de la transaction, et remplacez le numéro de version de suppression de l'enregistrement d'origine par le numéro de version actuel de la transaction, ce qui signifie qu'il a été supprimé. En fait, la mise à jour ici équivaut à supprimer et ajouter un autre enregistrement.

3. Les verrous optimistes et les verrous pessimistes

Les verrous sont divisés en verrous pessimistes et verrous optimistes du point de vue de l'utilisation. Les données trouvées peuvent être modifiées par d'autres, donc lors de l'interrogation, ce lot de données est verrouillé pour empêcher les autres de l'exploiter ; le verrouillage optimiste a une attitude très optimiste et estime qu'il est fondamentalement impossible que les données que j'ai trouvées soient modifiées par d'autres. .Modifiez, afin que ce lot de données ne soit pas verrouillé lors de l'interrogation, et lorsque la modification est soumise, confirmez si elle a été modifiée par d'autres. Il n'est pas trop tard pour rattraper.

Mise en œuvre du verrouillage optimiste et du verrouillage pessimiste :

● Le verrouillage pessimiste peut être facilement résolu au niveau de la base de données, en utilisant select... pour la mise à jour, lors de l'interrogation Just lock cette partie des données.

● La mise en œuvre du verrouillage optimiste est plus compliquée que le verrouillage pessimiste. Vous pouvez mettre une colonne de numéro de version dans la base de données, et lors de la mise à jour, le numéro de version est +1 pour confirmer si les données que j'ai trouvées ont été modifiées. par d'autres. Ceux qui sont modifiés ne sont pas mis à jour ou le programme lève une exception.

Devrions-nous utiliser le verrouillage optimiste ou le verrouillage pessimiste :

Du point de vue des performances, le verrouillage optimiste a de meilleures performances. Il n'y a pas d'opération de verrouillage entre la requête et la mise à jour, mais elle. est difficile à mettre en œuvre. Pas aussi simple qu’un verrouillage pessimiste et peut mal tourner. Le facteur à considérer est donc de savoir si la concurrence du système est élevée ? Quelle est la probabilité d’un conflit ? Lorsque la concurrence est élevée, il est préférable d'utiliser le verrouillage optimiste, sinon il est préférable d'utiliser une méthode simple comme le verrouillage pessimiste.

Tutoriel vidéo MySQL recommandé, adresse :

https://www.php.cn/course/list/51.html

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!