ध्यान दें कि आप प्रति टेबल के आधार पर नोलॉक निर्दिष्ट कर सकते हैं।
मैं आम तौर पर जटिल चयन प्रश्नों में नोलॉक का उपयोग करता था, लेकिन केवल छोटी लुकअप टेबल के लिए जो लगभग कभी नहीं बदला, और केवल डिस्प्ले डेटा के लिए। आप उन तालिकाओं को जानते हैं जो वर्तमान छमाही के लिए कीमतों को सूचीबद्ध करती हैं, या स्ट्रिंग्स आदि के लिए आईडी का लुकअप। ऐसी सामग्री जो केवल बड़े अपडेट के साथ बदलती है जिसके बाद सर्वर आमतौर पर वैसे भी नियमित रूप से पुनरारंभ होते हैं।
इसने प्रदर्शन में उल्लेखनीय रूप से सुधार किया, सबसे व्यस्त समय में गतिरोध की संभावना को कम कर दिया, और इससे भी महत्वपूर्ण बात यह है कि यह उन प्रश्नों के लिए सबसे खराब स्थिति के क्षणों में वास्तव में ध्यान देने योग्य था जो बहुत सारी तालिकाओं को छूते थे (जो तार्किक है, उन्हें कम ताले प्राप्त करने होते हैं, और वे साइडटेबल्स अक्सर लगभग हर जगह उपयोग किया जाता है, अक्सर 7-8 से घटकर 4 टेबल हो जाते हैं जिन्हें लॉक करने की आवश्यकता होती है)
लेकिन इसे जोड़ने में बहुत सावधानी बरतें, इसे जल्दी न करें और इसे नियमित रूप से न करें। ठीक से उपयोग करने पर यह चोट नहीं पहुँचाएगा, लेकिन अनुचित तरीके से उपयोग किए जाने पर यह बहुत चोट पहुँचाएगा।
अत्यधिक महत्वपूर्ण सामग्री, गणना करने वाले सामान आदि के लिए इसका उपयोग न करें, क्योंकि यह असंगत हो जाएगा, कुछ भी जो जल्दी या बाद में लिखने की ओर ले जाता है।
ऐसा ही एक अन्य अनुकूलन ROWLOCK है, जो केवल पंक्ति स्तर पर लॉक होता है। यह मुख्य रूप से उन तालिकाओं को अद्यतन करते समय (या हटाते समय) उपयोगी होता है जहाँ पंक्तियाँ एक दूसरे से संबंधित नहीं होती हैं, जैसे वे तालिकाएँ जहाँ आप केवल लॉग रिकॉर्ड में डालते हैं (और जिस क्रम में उन्हें डाला जाता है वह कोई मायने नहीं रखता)। यदि आपके पास एक योजना है कि किसी लेन-देन के अंत में किसी तालिका में एक लॉग रिकॉर्ड लिखा जाता है, तो यह काफी तेज भी हो सकता है।
यदि आपके डेटाबेस में अपेक्षाकृत कम प्रतिशत लिखता है तो यह इसके लायक नहीं हो सकता है। मेरा पढ़ने:लिखने का अनुपात 2:1 से कम था।
इस पर काम करते समय मेरे द्वारा सहेजे गए कुछ URL:
http://www.developerfusion.com/article/1688/ sql-server-locks/4/
