कई बार OPTION(RECOMPILE) . का उपयोग करने पर समझ में आता है। मेरे अनुभव में यह एकमात्र समय एक व्यवहार्य विकल्प है जब आप गतिशील एसक्यूएल का उपयोग कर रहे हैं। इससे पहले कि आप यह पता लगाएं कि यह आपकी स्थिति में समझ में आता है या नहीं, मैं आपके आंकड़ों के पुनर्निर्माण की अनुशंसा करता हूं। यह निम्नलिखित को चलाकर किया जा सकता है:
EXEC sp_updatestats
और फिर अपनी निष्पादन योजना को फिर से बनाना। यह सुनिश्चित करेगा कि जब आपकी निष्पादन योजना बनाई जाएगी तो यह नवीनतम जानकारी का उपयोग करेगी।
OPTION(RECOMPILE) जोड़ना हर बार जब आपकी क्वेरी निष्पादित होती है तो निष्पादन योजना का पुनर्निर्माण करता है। मैंने कभी नहीं सुना है कि creates a new lookup strategy . के रूप में वर्णित है लेकिन हो सकता है कि हम एक ही चीज़ के लिए अलग-अलग शब्दों का इस्तेमाल कर रहे हों।
जब एक संग्रहित प्रक्रिया बनाई जाती है (मुझे संदेह है कि आप .NET से एड-हॉक एसक्यूएल को कॉल कर रहे हैं लेकिन यदि आप पैरामीटरयुक्त क्वेरी का उपयोग कर रहे हैं तो यह एक संग्रहित प्रो कॉल बन जाता है) SQL सर्वर इस क्वेरी के लिए सबसे प्रभावी निष्पादन योजना निर्धारित करने का प्रयास करता है आपके डेटाबेस में डेटा और पारित पैरामीटर (पैरामीटर स्नीफिंग) के आधार पर, और फिर इस योजना को कैश करता है। इसका मतलब यह है कि यदि आप क्वेरी बनाते हैं जहां आपके डेटाबेस में 10 रिकॉर्ड हैं और फिर 100,000,000 रिकॉर्ड होने पर इसे निष्पादित करते हैं तो कैश्ड निष्पादन योजना अब सबसे प्रभावी नहीं हो सकती है।
संक्षेप में - मुझे कोई कारण नहीं दिखता कि OPTION(RECOMPILE) यहां लाभ होगा। मुझे संदेह है कि आपको बस अपने आंकड़े और अपनी निष्पादन योजना को अपडेट करने की आवश्यकता है। आपकी स्थिति के आधार पर पुनर्निर्माण के आँकड़े DBA कार्य का एक अनिवार्य हिस्सा हो सकते हैं। यदि आपको अपने आँकड़े अपडेट करने के बाद भी समस्या हो रही है, तो मैं दोनों निष्पादन योजनाओं को पोस्ट करने का सुझाव दूंगा।
और आपके प्रश्न का उत्तर देने के लिए - हां, मैं कहूंगा कि हर बार जब आप क्वेरी निष्पादित करते हैं तो निष्पादन योजना को पुन:संकलित करना आपके सर्वोत्तम विकल्प के लिए बेहद असामान्य है।
