Je voyais mes développeurs seniors utiliser WITH (NOLOCK) lors des requêtes dans SQL Server et je me demandais pourquoi ils utilisaient. Je l’ai exploré et j’ai découvert qu’il est utile pour améliorer les performances lors de l’exécution de la requête. Cependant, il y a un inconvénient à l’utiliser. L’inconvénient est qu’on peut ne pas être sûr de recevoir les données actuellement mises à jour dans le tableau, c’est-à-dire : sans protection contre le verrouillage, on ne peut pas garantir que les données ne le sont pas Changeant pendant le temps d’exécution de la requête. J’ai consulté ce lien et je l’ai trouvé assez utile.
Pour améliorer les performances des requêtes SQL, de manière générale, la première considération est de créer un index. En fait, en plus de l’établissement d’index, lorsque nous placons des commandes SQL, ajouter une section AVEC (NOLOCK) à la syntaxe peut améliorer le phénomène de verrouillage des jeux de données dans un environnement avec un grand nombre de requêtes en ligne, améliorant ainsi la performance des requêtes.
Cependant, il faut noter que SQL SELECT avec (NOLOCK) peut provoquer une lecture sale.
Par exemple:
Parce que SQL Server effectue la vérification de cohérence des verrous correspondante. Pour améliorer la performance globale des requêtes dans la base de données, ajoutez WITH (NOLOCK) à la fin du nom de la table dans votre syntaxe SELECT, bien que (NOLOCK) soit également acceptable, mais Microsoft recommande toujours d’ajouter WITH.
En plus du simple SELECT, vous pouvez aussi utiliser la syntaxe SELECT avec JOIN. Mais SUPPRIMER, INSÉRER, METTRE À JOUR et d’autres commandes qui nécessitent des transactions ne sont pas bonnes...
Certains fichiers indiquent que l’efficacité des requêtes SQL peut être augmentée de 33 % avec WITH (NOLOCK).
Ajouter WITH (NOLOCK) indique à SQL Server que notre commande SELECT n’a pas besoin de prendre en compte l’état du verrouillage transactionnel de la table actuelle, donc les performances seront significativement améliorées, et le phénomène de verrouillage du système de base de données sera considérablement réduit (y compris le blocage mort).
À noter que, comme WITH (NOLOCK) ne prend pas en compte le verrouillage de transaction de la table courante, donc lorsqu’il y a des données dans plusieurs phases d’une transaction (par exemple, une transaction sur plusieurs tables – > comme un système de retrait), WITH (NOLOCK) ignorera les données actuellement en traitement du processus de transaction...
Pour être franc, c’est-à-dire que lorsqu’on utilise NoLock, il permet de lire des données modifiées mais dont la transaction n’a pas encore été terminée. Par conséquent, si vous devez prendre en compte l’intégrité en temps réel des données transactionnelles, vous devriez réfléchir sérieusement à utiliser WITH (NOLOCK).
Si vous n’avez pas besoin de considérer les transactions, WITH (NOLOCK) peut être une référence utile.
Note 1 : AVEC ( < table_hint > )
Spécifie le balayage de table, un ou plusieurs index utilisés par l’optimiseur de requêtes,
Ou par l’optimiseur de requêtes pour exploiter cette table de données et utiliser le mode verrouillage pour cette affirmation.
Note 2 : WITH (NOLOCK) est équivalent à READ UNCOMMITTED
Enfin, parlons de quelques petites différences entre nolock et with(nolock) :
1 : Les synonymes en SQL05, seuls avec (nolock) sont pris en charge ;
2 : avec (nolock) s’écrit très facilement puis spécifie l’index.
Lorsque vous interrogez des instructions entre serveurs, vous ne pouvez pas utiliser avec (nolock), seulement avec nolock
Lors de requêtes sur le même serveur, on peut utiliser à la fois (nolock) et nolock
Comme quoi
Code SQL
select * from [IP].a.dbo.table1 avec (nolock) Cela vous fera apparaître l’erreur select * from a.dbo.table1 avec (nolock). Cela fonctionnera |
Publié sur 08/01/2016 17:58:31
|
|
|
