इस उत्तर में मैं मूल अवलोकन पर ध्यान केंद्रित कर रहा हूं:ईएफ द्वारा उत्पन्न क्वेरी धीमी है, लेकिन जब वही क्वेरी एसएसएमएस में चलती है तो यह तेज होती है।
इस व्यवहार की एक संभावित व्याख्या है पैरामीटर सूँघना ।
तो, ईएफ एक क्वेरी उत्पन्न करता है जिसमें कुछ पैरामीटर होते हैं। पहली बार जब आप इस क्वेरी को चलाते हैं तो सर्वर इस क्वेरी के लिए उन पैरामीटरों के मानों का उपयोग करके एक निष्पादन योजना बनाता है जो पहले रन में प्रभावी थे। वह योजना आमतौर पर बहुत अच्छी होती है। लेकिन, बाद में आप पैरामीटर के लिए अन्य मानों का उपयोग करके वही ईएफ क्वेरी चलाते हैं। यह संभव है कि मापदंडों के नए मूल्यों के लिए पहले से तैयार की गई योजना इष्टतम नहीं है और क्वेरी धीमी हो जाती है। सर्वर पिछली योजना का उपयोग करता रहता है, क्योंकि यह अभी भी वही क्वेरी है, बस पैरामीटर के मान भिन्न हैं।
यदि इस समय आप क्वेरी टेक्स्ट लेते हैं और इसे सीधे SSMS में चलाने का प्रयास करते हैं, तो सर्वर एक नई निष्पादन योजना बनाएगा, क्योंकि तकनीकी रूप से यह वही क्वेरी नहीं है जो EF एप्लिकेशन द्वारा जारी की जाती है। यहां तक कि एक वर्ण अंतर भी पर्याप्त है, सत्र सेटिंग्स में कोई भी बदलाव सर्वर के लिए क्वेरी को एक नया मानने के लिए भी पर्याप्त है। नतीजतन, सर्वर के पास कैश में समान क्वेरी के लिए दो योजनाएं हैं। पैरामीटर के नए मानों के लिए पहली "धीमी" योजना धीमी है, क्योंकि यह मूल रूप से विभिन्न पैरामीटर मानों के लिए बनाई गई थी। दूसरी "तेज़" योजना मौजूदा पैरामीटर मानों के लिए बनाई गई है, इसलिए यह तेज़ है।
लेख एप्लिकेशन में धीमा, SSMS में तेज़ एरलैंड द्वारा सोमरस्कोग इसे और अन्य संबंधित क्षेत्रों को और अधिक विवरण में समझाता है।
कैश्ड योजनाओं को त्यागने और सर्वर को उन्हें पुन:उत्पन्न करने के लिए बाध्य करने के कई तरीके हैं। तालिका बदलना या तालिका अनुक्रमणिका बदलना यह करना चाहिए - इसे "धीमी" और "तेज़" दोनों, इस तालिका से संबंधित सभी योजनाओं को त्याग देना चाहिए। फिर आप पैरामीटर के नए मूल्यों के साथ ईएफ एप्लिकेशन में क्वेरी चलाते हैं और एक नई "तेज" योजना प्राप्त करते हैं। आप एसएसएमएस में क्वेरी चलाते हैं और पैरामीटर के नए मूल्यों के साथ दूसरी "तेज़" योजना प्राप्त करते हैं। सर्वर अभी भी दो योजनाएँ बनाता है, लेकिन दोनों योजनाएँ अब तेज़ हैं।
एक अन्य प्रकार OPTION(RECOMPILE) adding जोड़ रहा है क्वेरी के लिए। इस विकल्प के साथ सर्वर जनरेटेड प्लान को अपने कैशे में स्टोर नहीं करेगा। इसलिए, हर बार जब क्वेरी चलती है तो सर्वर योजना बनाने के लिए वास्तविक पैरामीटर मानों का उपयोग करेगा (यह सोचता है) दिए गए पैरामीटर मानों के लिए इष्टतम होगा। नकारात्मक पक्ष योजना निर्माण का एक अतिरिक्त ऊपरी भाग है।
उदाहरण के लिए, पुराने आँकड़ों के कारण सर्वर अभी भी इस विकल्प के साथ "खराब" योजना चुन सकता है। लेकिन, कम से कम, पैरामीटर सूँघने से कोई समस्या नहीं होगी।
जो लोग यह जानना चाहते हैं कि OPTION (RECOMPILE) कैसे जोड़ें? EF द्वारा जनरेट की गई क्वेरी का संकेत इस उत्तर पर एक नज़र डालें:
https://stackoverflow.com/a/26762756/4116017
