l’autre jour, pendant L’atelier pratique de réglage des performances de SQL Server, Je suis entré dans une situation très intéressante. Lors du réglage d’une requête, nous avons eu une situation où nous devions vérifier si la requête est verrouillée lors de l’exécution de not., Pour tester notre théorie, nous avons dû mettre un indice nolock pour chaque table de la requête longue. Cependant, il n’était pas possible de le faire car la procédure stockée était super énorme et impliquait plus de 90 tables et 14 vues dans plusieurs instructions SQL. C’était en effet un énorme défi pour une équipe de développeurs de modifier ce SP. Si jamais vous faites face à de telles situations, vous ne devriez pas stresser. Il existe un moyen beaucoup plus simple de lire les données non validées.,
avant de continuer à lire cet article de blog, veuillez noter que personnellement, je ne préfère pas utiliser pour NOLOCK conseils dans mon entreprise, car il lira les données sales et souvent la lecture des données non validées crée des problèmes avec l’intégrité de la base de données. Il existe de nombreuses façons de régler votre requête plutôt que d’utiliser NOLOCK hint ou d’utiliser l’isolation de transaction non validée en lecture.
voyons d’abord un exemple simple comment NOLOCK astuce fonctionne avec plusieurs tables.,
maintenant, nous allons convertir le même script pour utiliser l’isolation de transaction non validée en lecture.
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDGOSELECT *FROM . ctINNER JOIN . spON ct.StateProvinceID = sp.StateProvinceIDGOSET TRANSACTION ISOLATION LEVEL READ COMMITTEDGO
techniquement, il n’y a absolument aucune différence entre les performances et l’impact des deux méthodes. Je préfère utiliser la deuxième méthode, plus souvent qu’il est plus facile d’écrire et de tester. Encore une fois, si possible, j’aime rester à l’écart de la lecture des méthodes non validées pour lire les données.
