Pourquoi utiliser un niveau d'isolation READ UNCOMMITTED ?

Ce niveau d'isolement autorise les lectures sales. Une transaction peut voir des modifications non validées apportées par une autre transaction.

Pour maintenir le plus haut niveau d'isolation, un SGBD acquiert généralement des verrous sur les données, ce qui peut entraîner une perte de concurrence et une surcharge de verrouillage élevée. Ce niveau d'isolement détend cette propriété.

Vous voudrez peut-être consulter l'article de Wikipedia sur READ UNCOMMITTED pour quelques exemples et lectures supplémentaires.

Vous pourriez également être intéressé par l'article de blog de Jeff Atwood sur la façon dont lui et son équipe ont abordé un problème de blocage au début de Stack Overflow. D'après Jeff :

Mais est nolock dangereux ? Pourriez-vous finir par lire des données invalides avec read uncommitted sur? Oui, en théorie. Vous ne manquerez pas d'astronautes de l'architecture de bases de données qui commenceront à vous lâcher la science ACID et qui déclencheront l'alarme incendie du bâtiment lorsque vous leur direz que vous voulez essayer nolock .C'est vrai :la théorie fait peur. Maisvoici ce que je pense :"En théorie, il n'y a pas de différence entre la théorie et la pratique. En pratique, il y en a."

Je ne recommanderais jamais d'utiliser nolock en tant que solution générale d'huile de serpent "bonne pour ce qui vous afflige" pour tous les problèmes de blocage de base de données que vous pourriez avoir. Vous devez d'abord essayer de diagnostiquer la source du problème.

Mais en pratique, en ajoutant nolock aux requêtes dont vous savez absolument qu'elles sont simples, les affaires directes en lecture seule ne semblent jamais conduire à des problèmes... Tant que vous savez ce que vous faites.

Une alternative au READ UNCOMMITTED le niveau que vous voudrez peut-être considérer est le READ COMMITTED SNAPSHOT . Je cite à nouveau Jeff :

Les instantanés reposent sur une toute nouvelle méthode de suivi des modifications de données... plus qu'un léger changement logique, cela nécessite que le serveur gère les données physiquement différemment. Une fois cette nouvelle méthode de suivi des modifications de données activée, elle crée une copie ou un instantané de chaque modification de données. En lisant ces instantanés plutôt que les données en direct en cas de conflit, les verrous partagés ne sont plus nécessaires lors des lectures et les performances globales de la base de données peuvent augmenter.