Niveaux d’Isolement des Transactions

Le niveau d’isolement des transactions est compris comme un état au sein des bases de données qui spécifie la quantité de données visibles pour une instruction dans une transaction, en particulier lorsque les mêmes données sont accédées par de nombreuses transactions en même temps. Imaginons une situation où nous avons une table Customers de 1 million de lignes occupant 10 Go d’espace disque. À 9 heures, nous lançons une requête “SELECT * FROM Customers”, qui interroge toutes les lignes de la table. Dans notre cas, cette requête prend environ 5 minutes pour s’exécuter complètement. Ce temps est nécessaire pour parcourir complètement notre table et récupérer les lignes. Ce type de requête effectue une analyse complète de la table et ne peut être recommandé du point de vue de la performance. À 9:01, l’utilisateur B met à jour la dernière ligne de la table Customers et valide la modification. Peu de temps après, notre requête arrive à la dernière ligne modifiée par l’utilisateur B. Alors, que va-t-il se passer ? Verrons-nous la valeur de ligne originale ou bien la valeur modifiée ? La nouvelle valeur de ligne est légitime et validée, mais elle a été mise à jour après le début de notre requête.

Le résultat de notre requête dépend du niveau d’isolement de la transaction. Fondamentalement, il existe quatre niveaux d’isolement expliqués ci-dessous :

Lecture non validée. Nous verrons les modifications apportées par l’utilisateur B. Ce niveau d’isolement est aussi appelé “lectures sales”, ce qui signifie que les données lues ne sont pas cohérentes avec d’autres parties de la table ou de la requête, et peuvent ne pas avoir encore été validées. Les “lectures sales” assurent les meilleures performances, car les données sont lues directement des blocs de la table sans validation.
Lecture validée. Nous ne verrons pas les modifications apportées par l’utilisateur B. Cela se produit car avec ce niveau d’isolement de la requête, les lignes récupérées par une requête sont les lignes qui avaient été validées avant le début de la requête. Cela signifie que les modifications apportées par l’utilisateur B n’étaient pas présentes lorsque la requête a commencé, donc les modifications ne seront pas incluses dans le résultat de la requête.
Lecture répétable. Nous ne verrons pas les modifications apportées par l’utilisateur B. Cela se produit en raison du fait qu’au niveau d’isolement de lecture répétable, les lignes récupérées par une requête sont les lignes qui avaient été validées lorsque la transaction a été commencée. Cela signifie que les modifications apportées par l’utilisateur B n’étaient pas présentes lorsque la transaction a commencé et, par conséquent, ne seront pas incluses dans le résultat de la requête. “Toutes les lectures cohérentes au sein de la même transaction lisent le snapshot établi par la première lecture” (extrait de la documentation MySQL)
Sérialisable. Ce niveau d’isolement signifie que toutes les transactions de base de données se produisent de manière complètement isolée. Dans ce niveau d’isolement, toutes les transactions sont exécutées en série, l’une après l’autre. Le SGBD peut exécuter deux transactions ou plus en même temps uniquement s’il est possible de maintenir l’illusion d’une exécution en série. En pratique, le niveau sérialisable est très semblable à la lecture répétable mais utilise une technique d’implémentation différente pour chaque moteur de base de données. Par exemple, dans Oracle, le niveau d’isolement de lecture répétable n’est pas supporté et le mode sérialisable offre le niveau d’isolement le plus élevé. Ce niveau d’isolement est similaire à la lecture répétable, mais InnoDB convertit implicitement toutes les instructions SELECT simples en “SELECT … LOCK IN SHARE MODE”.