Avant de travailler sur Stack Overflow, j'étais contre NOLOCK sur le principal que vous pourriez potentiellement effectuer un SELECT avec NOLOCK et récupérez les résultats avec des données qui peuvent être obsolètes ou incohérentes. Un facteur à prendre en compte est le nombre d'enregistrements pouvant être insérés/mis à jour en même temps qu'un autre processus peut sélectionner des données dans la même table. Si cela se produit souvent, il y a une forte probabilité de blocages à moins que vous n'utilisiez un mode de base de données tel que READ COMMITED SNAPSHOT .
J'ai depuis changé mon point de vue sur l'utilisation de NOLOCK après avoir vu comment il peut s'améliorer SELECT performances et éliminer les blocages sur un serveur SQL massivement chargé. Il y a des moments où vous ne vous souciez peut-être pas du fait que vos données ne sont pas exactement validées à 100 % et que vous avez besoin de résultats rapidement, même s'ils peuvent être obsolètes.
Posez-vous une question lorsque vous envisagez d'utiliser NOLOCK :
Ma requête inclut-elle une table contenant un nombre élevé de
INSERT/UPDATEcommandes et est-ce que je me soucie de savoir si les données renvoyées par une requête peuvent manquer ces modifications à un moment donné ?
Si la réponse est non, utilisez NOLOCK pour améliorer les performances.
NOLOCK mot-clé dans la base de code pour Stack Overflow et trouvé 138 instances, nous l'utilisons donc à plusieurs endroits. 
