La relation entre les verrous MySQL, les niveaux d'isolation des transactions et les applications

Niveau d'isolement des transactions de verrouillage MySQL et application
Dans la base de données, le niveau d'isolement des transactions est un concept très important, qui détermine le degré d'isolement entre les transactions simultanées. MySQL propose quatre niveaux d'isolation des transactions : READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ et SERIALIZABLE. Différents niveaux d'isolation des transactions ont différentes stratégies de verrouillage pour la lecture et l'écriture des données. Il est donc crucial de sélectionner et d'utiliser correctement le niveau d'isolation des transactions approprié dans votre application.

1. LIRE UNCOMMITTED : à ce niveau, les transactions peuvent lire les données non validées d'autres transactions. Cela signifie qu'une lecture sale peut se produire, c'est-à-dire que des données non vérifiées sont lues. Ce niveau n'est généralement pas recommandé sauf si des circonstances particulières nécessitent l'obtention de données en temps très réel.
2. READ COMMITTED : À ce niveau, les transactions ne peuvent lire que les données soumises. Cela évite les problèmes de lecture incorrecte, mais peut entraîner des problèmes de lecture non reproductibles. La lecture non répétable fait référence à la lecture des mêmes données deux fois dans la même transaction, mais les résultats sont incohérents. En effet, d'autres transactions peuvent avoir mis à jour les données lors de l'exécution de la transaction.
3. LECTURE RÉPÉTABLE : à ce niveau, une transaction peut lire les mêmes données plusieurs fois avec des résultats cohérents. Ceci est réalisé en verrouillant les données pendant le processus de lecture. Au niveau REPEATABLE READ, l'opération de lecture partagera le verrou sur les lignes de données qui remplissent les conditions, de sorte que les autres transactions pourront uniquement lire les données mais ne pourront pas les modifier. Toutefois, des problèmes de lecture fantôme peuvent toujours survenir. La lecture fantôme fait référence à la lecture de données dans une plage deux fois au cours de la même transaction, mais les résultats sont incohérents. En effet, lors de l'exécution de la transaction, d'autres transactions peuvent avoir inséré ou supprimé des données qui remplissent les conditions.
4. SERIALIZABLE : A ce niveau, les transactions sont exécutées en série. Cela signifie qu'une seule transaction peut modifier les données au même moment et que d'autres transactions attendent que le verrou soit libéré. Ce niveau peut éviter complètement les problèmes de lectures sales, de lectures non répétables et de lectures fantômes, mais il a également un impact considérable sur les performances de concurrence, car vous devez attendre que d'autres transactions libèrent le verrou.

Ce qui suit utilise des exemples de code spécifiques pour démontrer les stratégies de verrouillage sous différents niveaux d'isolement des transactions :

Créez d'abord une table de test :

CREATE TABLE test_table (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  age INT
);

Ensuite, nous démontrons les stratégies de verrouillage sous différents niveaux d'isolement des transactions :

1. LIRE UNCOMMITTED :

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Dans cet exemple, la transaction 1 lit les données modifiées mais non validées par la transaction 2.

2. READ COMMITTED :

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Dans cet exemple, la transaction 1 ne peut lire que les données soumises par la transaction 2.

3. LECTURE RÉPÉTABLE :

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Dans cet exemple, la transaction 1 ajoute un verrou partagé lors de la lecture des données, et la transaction 2 attend que la transaction 1 libère le verrou partagé avant de pouvoir être exécutée.

4. SÉRIALISABLE :

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Dans cet exemple, la transaction 1 ajoute un verrou partagé lors de la lecture des données, et la transaction 2 attend que la transaction 1 libère le verrou partagé avant de pouvoir être exécutée.

   Grâce aux exemples de code ci-dessus, nous pouvons voir comment les stratégies de verrouillage fonctionnent sous différents niveaux d'isolement des transactions. Dans le développement réel d'applications, il est indispensable de choisir le niveau d'isolation des transactions approprié, qui peut être sélectionné en fonction de scénarios commerciaux spécifiques et d'exigences de performances.

   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!