Une brève discussion sur l'isolation des transactions MySQL

Cet article parle de l'isolation des transactions MySQL. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

Introduction aux transactions

Une transaction est un ensemble de requêtes SQL atomiques, ou un travail indépendant unité. En bref, les instructions au sein d’une transaction s’exécutent toutes avec succès ou échouent toutes.

Dans Mysql, la prise en charge des transactions est implémentée au niveau de la couche moteur, mais tous les moteurs Mysql ne prennent pas en charge les transactions. Par exemple, le moteur MyISAM ne prend pas en charge les transactions. C'est l'une des raisons importantes pour lesquelles MyISAM a été remplacé par InnoDB. .

En matière de transactions, on pensera certainement à ACID :

• Atomicité

• Cohérence

• Isolement

• Durabilité

Niveau d'isolement

Lorsque plusieurs transactions sont exécutées simultanément dans la base de données, des problèmes tels que des lectures sales, des lectures non répétables et des lectures fantômes peuvent survenir en raison du concept de niveau d'isolation des transactions.

Le standard SQL définit quatre niveaux d'isolement :

1. READ UNCOMMITTED (lecture non validée)

   Modifications dans la transaction, même si elles n'ont pas encore été commités , sont visibles par les autres transactions. Les transactions peuvent lire des données non validées, également appelées lecture sale.

2. LECTURE COMMITTED

   Une fois qu'une transaction est validée, les modifications peuvent être vues par d'autres transactions. Ce niveau est également appelé lecture non répétable, car si la même requête est exécutée deux fois dans une transaction, les résultats peuvent être différents.

3. REPEATABLE READ (lecture répétable)

   Lors de l'exécution d'une transaction, les données vues au démarrage de la transaction sont toujours cohérentes. Bien entendu, à ce niveau, les modifications de données non validées sont également invisibles pour les autres transactions.

4. SERIALIZABLE (sérialisable)

   Pour la même ligne d'enregistrements, l'écriture et la lecture seront verrouillées. Lorsqu'un conflit de verrouillage en lecture-écriture se produit, la transaction est accessible ultérieurement. doit Attendre la fin de la transaction précédente avant de continuer entraînera de nombreux problèmes de délai d'attente et de conflit de verrouillage.

En termes de mise en œuvre, une vue sera créée dans la base de données, et la logique de la vue prévaudra lors de l'accès.

Sous le niveau d'isolement de lecture répétable, cette vue est créée au démarrage de la transaction, et cette vue est utilisée pendant toute la transaction.

Sous le niveau d'isolement lecture-validation, cette vue est créée lorsque l'instruction SQL commence à s'exécuter.

Sous le niveau d'isolement de lecture non validée, la dernière valeur de l'enregistrement est renvoyée directement, sans le concept de vue.

Sous le niveau d'isolement sérialisé, verrouillez directement pour éviter l'accès parallèle.

est configuré en réglant le paramètre de démarrage transaction-isolation au niveau d'isolement souhaité.

Affichez les paramètres actuels :

mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)

En bref, c'est raisonnable s'il existe. Différents niveaux d'isolement conviennent à différents scénarios. Nous devons décider en fonction du scénario commercial.

Mise en œuvre de l'isolement des transactions

Dans Mysql, en fait, la mise à jour de chaque enregistrement enregistrera également une opération de rollback via l'opération de rollback. , la dernière valeur de l'état précédent peut être obtenue.

Le système déterminera automatiquement que lorsqu'aucune transaction ne doit être annulée, le journal d'annulation sera supprimé.

Pourquoi il n'est pas recommandé d'utiliser des transactions longues :

Les transactions longues signifient qu'il y aura de très anciennes vues de transactions dans le système puisque ces transactions peuvent accéder à n'importe quelle donnée de la base de données à tout moment. , avant de soumettre cette transaction, les enregistrements d'annulation pouvant être utilisés dans la base de données doivent être conservés, ce qui prendra beaucoup d'espace de stockage. Dans le même temps, les transactions longues occupent également des ressources de verrouillage et peuvent faire tomber la bibliothèque entière.

Comment démarrer la transaction

• Démarrer explicitement la déclaration de transaction, commencer ou démarrer la transaction, valider signifie valider, return Utiliser la restauration.

• set autocommit = 0, cette commande désactivera la soumission automatique du fil, ce qui signifie que si vous exécutez une instruction select, la transaction sera démarrée et ne sera pas automatiquement validée jusqu'à ce que vous exécutiez activement la validation ou la restauration, ou que vous vous déconnectiez.

Ma suggestion personnelle est de démarrer explicitement la transaction via la première méthode pour éviter l'apparition de transactions longues.

Dans le cas de set autocommit = 1, une transaction démarrée explicitement avec start sera validée si commit est exécuté. Si vous exécutez un travail et une chaîne de validation, la transaction est validée et la transaction suivante est automatiquement démarrée, ce qui évite également la surcharge liée à l'exécution à nouveau de l'instruction de début.

Interroger les transactions longues :

L'instruction suivante consiste à interroger les transactions d'une durée supérieure à 60 s

mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60;
Empty set (0.00 sec)

Pour résumer, pendant le processus de développement, nous essayez d'en faire le moins possible. Utilisez des transactions longues. Si cela ne peut être évité, assurez-vous que l'espace de journalisation logique est suffisamment grand et prend en charge la croissance dynamique de l'espace de journalisation. Surveillez la table Innodb_trx et signalez une alarme de transaction longue.

Recommandé : "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!