सबसे पहले, सुनिश्चित करें कि आप प्रदर्शन को ठीक से प्रोफाइल कर रहे हैं। उदाहरण के लिए, ADO.NET से दो बार क्वेरी चलाएँ और देखें कि क्या दूसरी बार पहली बार की तुलना में बहुत तेज़ है। यह ऐप को संकलित करने और डिबगिंग इन्फ्रास्ट्रक्चर के रैंप पर चलने के लिए प्रतीक्षा करने के ऊपरी हिस्से को हटा देता है।
इसके बाद, ADO.NET और SSMS में डिफ़ॉल्ट सेटिंग्स की जाँच करें। उदाहरण के लिए, यदि आप SSMS में SET ARITHABORT OFF चलाते हैं, तो आप पा सकते हैं कि यह अब ADO.NET का उपयोग करते समय उतना ही धीमा चलता है।
मुझे एक बार जो मिला वह यह था कि एसएसएमएस में सेट ARITHABORT OFF ने संग्रहित प्रो को फिर से संकलित किया और/या विभिन्न आंकड़ों का उपयोग किया। और अचानक SSMS और ADO.NET दोनों लगभग एक ही निष्पादन समय की रिपोर्ट कर रहे थे।
इसे जांचने के लिए, प्रत्येक रन के लिए निष्पादन योजनाओं को देखें, विशेष रूप से syscacheobjects तालिका। वे शायद अलग होंगे।
किसी विशिष्ट संग्रहीत कार्यविधि पर 'sp_recompile' चलाना कैश से संबंधित निष्पादन योजना को छोड़ देगा, जो तब SQL सर्वर को प्रक्रिया के अगले निष्पादन पर संभवतः अधिक उपयुक्त योजना बनाने का मौका देता है।
अंत में, आप SSMS का उपयोग करके संपूर्ण प्रक्रिया कैश और मेमोरी बफ़र्स को साफ़ करने के लिए "न्युक इट फ्रॉम ऑर्बिट" दृष्टिकोण का प्रयास कर सकते हैं:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
अपनी क्वेरी का परीक्षण करने से पहले ऐसा करने से कैश्ड निष्पादन योजनाओं और पिछले परिणाम कैश के उपयोग को रोका जा सकता है।
