Quel est le niveau d'isolement des transactions MySQL ?

1. La notion de niveau d'isolement

Pourquoi devrions-nous considérer le niveau d'isolement ?

Étant donné que les transactions doivent être exécutées simultanément, et que l'exécution simultanée peut entraîner certains problèmes : lectures incorrectes, lectures non répétables et lectures virtuelles, certaines sont autorisées et d'autres ne sont pas autorisées. différents degrés ou le contrôle de la concurrence ne semble pas avoir différents niveaux d'isolement.

Les quatre niveaux d'isolement pris en charge par MySQL sont :

• TRANSACTION_READ_UNCOMMITTED : Lecture non validée. Cela signifie que la transaction A peut voir les modifications de la transaction B avant de s'engager. De cette manière, les données sales sont lues et les lectures non répétables et les lectures fantômes sont autorisées.

• TRANSACTION_READ_COMMITTED : Lecture validée (par défaut d'Oracle), indiquant que la lecture de données non validées n'est pas autorisée (pour éviter les lectures sales). Les lectures non répétables et les lectures fantômes sont toujours autorisées à ce niveau.

• TRANSACTION_REPEATABLE_READ : Lecture répétable (par défaut MySQL), indiquant que la transaction est garantie de pouvoir relire les mêmes données sans échec. Même si d'autres transactions modifient ces données, vous ne les verrez pas deux fois. être interrogé est différent. Mais la lecture fantôme se produit toujours.

• TRANSACTION_SERIALIZABLE : Sérialisation, est le niveau d'isolation de transaction le plus élevé, qui empêche les lectures sales, les lectures non répétables et les lectures fantômes. L'exécution en série équivaut à une opération monothread, avec la capacité de concurrence la plus faible.

Plus le niveau d'isolation des transactions est élevé, plus les performances sont dépensées pour éviter les conflits, c'est-à-dire que l'efficacité est faible. Au niveau « lecture répétable », cela peut en fait résoudre une partie du problème de lecture virtuelle, mais il ne peut pas empêcher le problème de lecture virtuelle provoqué par les mises à jour. Pour interdire l'apparition de lectures virtuelles, vous devez toujours définir le niveau d'isolement de sérialisation.

2. Testez le niveau d'isolement TRANSACTION_READ_UNCOMMITTED

Si le client A est annulé à ce moment-là, l'âge de Zhangsan dans la base de données est restauré à 20 , il est trop tard à ce moment-là, car le client B a déjà mis 21 pour faire des affaires.

Les deux clients retournent et abandonnent les modifications des données effectuées par la transaction actuelle, et l'âge de Zhangsan est restauré à 20

3. Testez le niveau d'isolement Transaction_Read_Commit est défini sur le niveau d'isolement de lecture soumis, donc aucune lecture sale n'a eu lieu dans la transaction B. Ceci est réalisé par divers mécanismes de verrouillage et le contrôle de version MVCC de la concurrence des transactions.

Sous le niveau d'isolement des lectures validées, l'interrogation des données validées peut provoquer des lectures non répétables, ce qui est autorisé. Étant donné que des lectures non répétables ont eu lieu, des lectures fantômes peuvent certainement se produire.

4. Testez le niveau d'isolement TRANSACTION_REPEATABLE_READ

Dans un certain sens, les lectures répétables peuvent éviter l'apparition de lectures fantômes. Parce que le niveau d’isolement de lecture reproductible actuel empêche les opérations d’insertion. Bien que le niveau d'isolement de lecture répétable puisse empêcher les opérations d'insertion et de suppression, il ne peut pas empêcher les opérations de mise à jour.

En fait, la transaction A a été insérée et soumise, aaa existe déjà, car la transaction B a mis à jour l'âge de aaa avec succès

Lorsque la même requête est exécutée deux fois avant et après, si le volume de données est différent, elle provoquera des fantômes. La lecture se produit. Pour résoudre complètement le problème de lecture fantôme, cela ne peut pas être réalisé avec le niveau d'isolement de lecture répétable. Le niveau d'isolement doit être élevé à la sérialisation

.

À en juger par le phénomène, la sérialisation peut résoudre la lecture fantôme. Lors d'une interrogation dans les mêmes conditions, l'insertion de données dans une autre table sera bloquée. Puisque la transaction B lit des données, la transaction A sera bloquée si elle écrit à nouveau des données. (implémenté avec des verrous en lecture-écriture, la lecture et la lecture sont autorisées, mais la lecture et l'écriture ne sont pas autorisées)

Le serveur MySQL ne laissera pas son propre thread exécutant les transactions être bloqué pour toujours, ce qui empêchera le verrou occupé par le thread actuel de pouvoir être libéré, provoquant l'exécution d'autres transactions. Le thread ne peut pas obtenir le verrou et est bloqué pour toujours. Si le thread exécutant la transaction attend trop longtemps, le mécanisme de délai d'attente sera déclenché, ce qui amènera le thread à libérer le verrou et à renvoyer une erreur

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!