Notice: This page requires JavaScript to function properly.
Please enable JavaScript in your browser settings or update your browser.
Apprendre Isolation | Acid
Optimisation SQL et Fonctionnalités de Requête

Isolation

Glissez pour afficher le menu

Dans le contexte des bases de données, l'isolation fait référence à la capacité d'un système de base de données à contrôler la visibilité des modifications effectuées par des transactions concurrentes. Elle garantit que les transactions fonctionnent de manière indépendante les unes des autres, évitant ainsi toute interférence et préservant l'intégrité des données.

Il existe 4 niveaux d'isolation en SQL :

  • read uncommitted ;
  • read committed ;
  • repeatable read ;
  • serializable.

Read uncommitted

Il s'agit du niveau d'isolation le plus bas, où les transactions peuvent voir les modifications effectuées par d'autres transactions même avant qu'elles ne soient validées. Ce niveau autorise les lectures sales, c'est-à-dire qu'une transaction peut lire des données qui ont été modifiées par une autre transaction mais pas encore validées.

Lectures sales

Note
Approfondir

Une lecture sale se produit lorsqu'une transaction lit des données qui ont été modifiées par une autre transaction mais pas encore validées.

Par exemple, imaginez deux transactions bancaires se produisant simultanément : la transaction A vérifie le solde de votre compte tandis que la transaction B dépose de l'argent sur votre compte. Si la transaction A voit le solde augmenté avant que la transaction B ne soit terminée, il s'agit d'une lecture sale, car le nouveau solde pourrait être annulé si la transaction B échoue.

dirty+read

Implémentation

Pour spécifier le niveau d'isolation d'une transaction, nous pouvons utiliser la commande suivante dans notre requête :

-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

/* Transaction query */
COMMIT;
  • SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; : Cette instruction modifie le niveau d'isolation de la transaction en cours à "Read Uncommitted", permettant à la transaction de lire potentiellement des données modifiées par d'autres transactions non validées ;

  • cette commande doit être utilisée uniquement à l'intérieur du bloc de transaction ! Sinon, elle n'aura aucun effet et le niveau d'isolation par défaut sera utilisé.

Nous pouvons également vérifier le niveau d'isolation actuel à l'aide de la commande suivante :
SHOW TRANSACTION ISOLATION LEVEL;

Read committed

Le niveau d'isolation Read Committed garantit qu'une transaction ne voit que les données qui ont été validées par d'autres transactions.
Cela signifie que les modifications non validées effectuées par d'autres transactions ne sont pas visibles pour les transactions fonctionnant sous Read Committed.
En conséquence, cela empêche les lectures sales en permettant à une transaction de lire uniquement des données validées. Cependant, ce niveau d'isolation présente des problèmes de lectures non répétables.

Lectures non répétables

Note
Approfondir

Une lecture non répétable se produit lorsqu'une transaction lit la même ligne plusieurs fois au sein de la même transaction, mais que les données récupérées changent entre les lectures en raison de modifications effectuées par d'autres transactions. Cette incohérence peut entraîner un comportement inattendu et des résultats incorrects.

Par exemple, imaginez une transaction qui interroge deux fois le solde du compte d'un client. La première requête retourne 1000 $, mais avant que la transaction ne se termine, une autre transaction dépose 500 $ sur le compte. Lorsque la seconde requête est exécutée, elle affiche 1500 $, ce qui conduit à une lecture non répétable, où les mêmes données sont lues différemment au sein d'une seule transaction en raison de modifications apportées par une autre transaction.

Le niveau d'isolation "Read committed" autorise les lectures non répétables car il verrouille l'opération de lecture sur les valeurs en cours de transaction non validée mais ne verrouille pas l'opération d'écriture.
En conséquence, il est possible d'écrire de nouvelles données dans la ligne qui est actuellement lue par une autre transaction.

Lecture non répétée

Mise à jour perdue

En raison de l'absence de verrouillage en écriture, il existe un autre problème avec le niveau d'isolation read committed : les mises à jour perdues.

Note
Pour aller plus loin

Une mise à jour perdue est une situation en gestion de base de données où une transaction écrase les modifications effectuées par une autre transaction, entraînant une perte de données. Cela se produit généralement lorsque plusieurs transactions tentent de mettre à jour les mêmes données simultanément, et que les modifications d'une transaction sont écrasées par une autre avant d'être validées dans la base de données.

Les mises à jour perdues se produisent lorsque deux transactions parallèles tentent de modifier la même ligne. En conséquence, la transaction validée en dernier écrase les valeurs validées par les autres transactions.

Lost_update

Implémentation

Nous pouvons également spécifier ce niveau d'isolation à l'aide des commandes suivantes :

-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

/* Transaction query */
COMMIT;

Il est important de noter que Read Committed est le niveau d'isolation par défaut pour la plupart des systèmes de gestion de bases de données, c'est pourquoi il n'est pas nécessaire de le spécifier.

question mark

Si une transaction lit des données qui ont été modifiées par une autre transaction non validée, quel type de lecture est-ce ?

Sélectionnez la réponse correcte

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 1. Chapitre 6

Demandez à l'IA

expand

Demandez à l'IA

ChatGPT

Posez n'importe quelle question ou essayez l'une des questions suggérées pour commencer notre discussion

Isolation

Dans le contexte des bases de données, l'isolation fait référence à la capacité d'un système de base de données à contrôler la visibilité des modifications effectuées par des transactions concurrentes. Elle garantit que les transactions fonctionnent de manière indépendante les unes des autres, évitant ainsi toute interférence et préservant l'intégrité des données.

Il existe 4 niveaux d'isolation en SQL :

  • read uncommitted ;
  • read committed ;
  • repeatable read ;
  • serializable.

Read uncommitted

Il s'agit du niveau d'isolation le plus bas, où les transactions peuvent voir les modifications effectuées par d'autres transactions même avant qu'elles ne soient validées. Ce niveau autorise les lectures sales, c'est-à-dire qu'une transaction peut lire des données qui ont été modifiées par une autre transaction mais pas encore validées.

Lectures sales

Note
Approfondir

Une lecture sale se produit lorsqu'une transaction lit des données qui ont été modifiées par une autre transaction mais pas encore validées.

Par exemple, imaginez deux transactions bancaires se produisant simultanément : la transaction A vérifie le solde de votre compte tandis que la transaction B dépose de l'argent sur votre compte. Si la transaction A voit le solde augmenté avant que la transaction B ne soit terminée, il s'agit d'une lecture sale, car le nouveau solde pourrait être annulé si la transaction B échoue.

dirty+read

Implémentation

Pour spécifier le niveau d'isolation d'une transaction, nous pouvons utiliser la commande suivante dans notre requête :

-- Start transaction
BEGIN;
-- Set the isolation level for the transaction
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

/* Transaction query */
COMMIT;
  • SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; : Cette instruction modifie le niveau d'isolation de la transaction en cours à "Read Uncommitted", permettant à la transaction de lire potentiellement des données modifiées par d'autres transactions non validées ;

  • cette commande doit être utilisée uniquement à l'intérieur du bloc de transaction ! Sinon, elle n'aura aucun effet et le niveau d'isolation par défaut sera utilisé.

Nous pouvons également vérifier le niveau d'isolation actuel à l'aide de la commande suivante :
SHOW TRANSACTION ISOLATION LEVEL;

Read committed

Le niveau d'isolation Read Committed garantit qu'une transaction ne voit que les données qui ont été validées par d'autres transactions.
Cela signifie que les modifications non validées effectuées par d'autres transactions ne sont pas visibles pour les transactions fonctionnant sous Read Committed.
En conséquence, cela empêche les lectures sales en permettant à une transaction de lire uniquement des données validées. Cependant, ce niveau d'isolation présente des problèmes de lectures non répétables.

Lectures non répétables

Note
Approfondir

Une lecture non répétable se produit lorsqu'une transaction lit la même ligne plusieurs fois au sein de la même transaction, mais que les données récupérées changent entre les lectures en raison de modifications effectuées par d'autres transactions. Cette incohérence peut entraîner un comportement inattendu et des résultats incorrects.

Par exemple, imaginez une transaction qui interroge deux fois le solde du compte d'un client. La première requête retourne 1000 $, mais avant que la transaction ne se termine, une autre transaction dépose 500 $ sur le compte. Lorsque la seconde requête est exécutée, elle affiche 1500 $, ce qui conduit à une lecture non répétable, où les mêmes données sont lues différemment au sein d'une seule transaction en raison de modifications apportées par une autre transaction.

Le niveau d'isolation "Read committed" autorise les lectures non répétables car il verrouille l'opération de lecture sur les valeurs en cours de transaction non validée mais ne verrouille pas l'opération d'écriture.
En conséquence, il est possible d'écrire de nouvelles données dans la ligne qui est actuellement lue par une autre transaction.

Lecture non répétée

Mise à jour perdue

En raison de l'absence de verrouillage en écriture, il existe un autre problème avec le niveau d'isolation read committed : les mises à jour perdues.

Note
Pour aller plus loin

Une mise à jour perdue est une situation en gestion de base de données où une transaction écrase les modifications effectuées par une autre transaction, entraînant une perte de données. Cela se produit généralement lorsque plusieurs transactions tentent de mettre à jour les mêmes données simultanément, et que les modifications d'une transaction sont écrasées par une autre avant d'être validées dans la base de données.

Les mises à jour perdues se produisent lorsque deux transactions parallèles tentent de modifier la même ligne. En conséquence, la transaction validée en dernier écrase les valeurs validées par les autres transactions.

Lost_update

Implémentation

Nous pouvons également spécifier ce niveau d'isolation à l'aide des commandes suivantes :

-- Start transaction
BEGIN;
-- Set the isolation level for the session
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

/* Transaction query */
COMMIT;

Il est important de noter que Read Committed est le niveau d'isolation par défaut pour la plupart des systèmes de gestion de bases de données, c'est pourquoi il n'est pas nécessaire de le spécifier.

Tout était clair ?

Comment pouvons-nous l'améliorer ?

Merci pour vos commentaires !

Section 1. Chapitre 6
some-alt