स्टैक ओवरफ्लो पर काम करने से पहले, मैं NOLOCK . के खिलाफ था प्रिंसिपल पर कि आप संभावित रूप से SELECT कर सकते हैं NOLOCK . के साथ और डेटा के साथ परिणाम वापस प्राप्त करें जो पुराने या असंगत हो सकते हैं। सोचने का एक कारक यह है कि एक ही समय में कितने रिकॉर्ड डाले/अपडेट किए जा सकते हैं, दूसरी प्रक्रिया उसी तालिका से डेटा का चयन कर सकती है। यदि ऐसा बहुत अधिक होता है तो जब तक आप डेटाबेस मोड जैसे READ COMMITED SNAPSHOT का उपयोग नहीं करते हैं, तब तक गतिरोध की उच्च संभावना है। ।
मैंने तब से NOLOCK . के उपयोग पर अपना दृष्टिकोण बदल दिया है यह देखने के बाद कि यह कैसे बेहतर हो सकता है SELECT प्रदर्शन के साथ-साथ बड़े पैमाने पर लोड किए गए SQL सर्वर पर गतिरोध को खत्म करना। कई बार आपको इस बात की परवाह नहीं होती है कि आपका डेटा बिल्कुल 100% प्रतिबद्ध नहीं है और आपको परिणाम जल्दी वापस चाहिए, भले ही वे पुराने हों।
NOLOCK . का उपयोग करने के बारे में सोचते समय स्वयं से एक प्रश्न पूछें :
क्या मेरी क्वेरी में एक तालिका शामिल है जिसमें उच्च संख्या में INSERT . है /UPDATE कमांड और क्या मुझे परवाह है कि किसी क्वेरी से लौटाए गए डेटा में किसी निश्चित क्षण में ये परिवर्तन गायब हो सकते हैं?
अगर उत्तर नहीं है, तो NOLOCK . का प्रयोग करें प्रदर्शन में सुधार करने के लिए।
NOLOCK . के लिए एक त्वरित खोज की है स्टैक ओवरफ्लो के लिए कोड बेस के भीतर कीवर्ड और 138 इंस्टेंस पाए गए, इसलिए हम इसे कुछ जगहों पर उपयोग करते हैं। 
