Niveaux d’Isolation des Transactions

Le niveau d’isolation des transactions est compris comme un état au sein des bases de données qui spécifie la quantité de données visible pour une instruction dans une transaction, en particulier lorsque les mêmes données sont accessibles par plusieurs transactions en même temps. Imaginons une situation où nous avons une table Clients de 1 million de lignes prenant 10 Go d’espace disque. À 9 heures, nous avons lancé 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’achever. Ce temps est nécessaire pour scanner entièrement notre table et récupérer les lignes. Ce type de requête effectue une analyse complète de la table et ne peut pas être recommandé du point de vue des performances. À 9h01, UserB met à jour la dernière ligne de la table Clients et valide le changement. Peu de temps après, notre requête arrive à la dernière ligne modifiée par UserB. Que va-t-il se passer ? Verrons-nous la valeur initiale de la ligne ou la valeur modifiée ? La nouvelle valeur de la 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’isolation de la transaction. En gros, il existe 4 niveaux d’isolation expliqués ci-dessous :

Lecture non validée (Read uncommitted). Nous verrons les modifications apportées par UserB. Ce niveau d’isolation est également appelé “lectures sales”, ce qui signifie que les données lues ne sont pas cohérentes avec les autres parties de la table ou de la requête, et peuvent ne pas encore avoir é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 (Read committed). Nous ne verrons pas les modifications apportées par UserB. Cela se produit car avec ce niveau d’isolation de 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 UserB n’étaient pas là 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 (Repeatable read). Nous ne verrons pas les modifications apportées par UserB. Cela se produit du fait que dans le niveau d’isolation 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 commencé. Cela signifie que les modifications apportées par UserB n’étaient pas là au début de la transaction et ne seront donc pas incluses dans le résultat de la requête. “Toutes les lectures cohérentes au sein de la même transaction lisent l’instantané établi par la première lecture” (d’après la documentation MySQL).
Sérialisable (Serializable). Ce niveau d’isolation signifie que toutes les transactions de base de données se produisent de manière complètement isolée. Dans ce niveau d’isolation, 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 si l’illusion d’une exécution en série peut être maintenue. En pratique, le sérialisable ressemble beaucoup à 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’isolation de lecture répétable n’est pas pris en charge et le sérialisable fournit le plus haut niveau d’isolation. Ce niveau d’isolation est comme la lecture répétable, mais InnoDB convertit implicitement toutes les instructions SELECT normales en “SELECT … LOCK IN SHARE MODE”.