जवाबों:
जवाब, हमेशा की तरह (ठीक है, ज्यादातर समय), निष्पादन योजना में निहित है।
कुछ ऑपरेटर हैं जिन्हें उन पंक्तियों को संसाधित करने से पहले उन तक पहुंचने के लिए सभी पंक्तियों की आवश्यकता होती है और उदाहरण के लिए, उन्हें नीचे की ओर से गुजरना होता है:
उन्हें या तो ब्लॉकिंग कहा जाता है, या इसके कारण ऑपरेटर बंद हो जाते हैं, और वे अक्सर चुने जाते हैं, जब ऑप्टिमाइज़र को लगता है कि आपके डेटा को खोजने के लिए उसे बहुत सारे डेटा को संसाधित करना होगा।
ऐसे अन्य ऑपरेटर हैं जो स्ट्रीमिंग को शुरू करने में सक्षम हैं, या किसी भी मिली हुई पंक्तियों को तुरंत पास कर रहे हैं
जब प्रश्न तुरंत डेटा लौटना शुरू करते हैं, लेकिन तुरंत समाप्त नहीं होते हैं, तो यह आमतौर पर एक संकेत है कि ऑप्टिमाइज़र ने ऑपरेटर्स का उपयोग करके जल्दी से कुछ पंक्तियों का पता लगाने और वापस करने की योजना को चुना जिसमें स्टार्ट अप की लागत कम है।
ऐसा आपके द्वारा या फिर ऑप्टिमाइज़र द्वारा शुरू किए गए पंक्ति लक्ष्यों के कारण हो सकता है।
यह भी हो सकता है कि अगर किसी कारण से किसी खराब योजना को चुना जाता है (एसएआरजीबिलिटी की कमी, पैरामीटर सूँघना, अपर्याप्त आंकड़े, आदि), लेकिन यह पता लगाने के लिए अधिक खुदाई होती है।
अधिक जानकारी के लिए, रोब फ़ार्ले के ब्लॉग की जाँच यहाँ
और पॉल व्हाइट की श्रृंखला पंक्ति लक्ष्यों पर यहाँ , यहाँ , यहाँ और यहाँ ।
यह भी ध्यान दिया जाना चाहिए कि, यदि आप SSMS के बारे में बात कर रहे हैं, तो पंक्तियाँ केवल एक बार दिखाई देती हैं, जब पूरा बफर भर जाता है, केवल विली-निली नहीं।
यदि मैं समझता हूं कि आप क्या देख रहे हैं, तो यह कैसे प्रबंधन स्टूडियो पंक्तियों को प्रस्तुत करता है , और SQL सर्वर पंक्तियों को कैसे लौटाता है, इसके साथ बहुत कम है । वास्तव में अक्सर जब आप SSMS को बड़े परिणाम दे रहे होते हैं और उन्हें ग्रिड में प्रस्तुत करने का प्रयास करते हैं, तो SSMS नहीं रख सकते हैं और SQL सर्वर एप्लिकेशन को अधिक पंक्तियों को संसाधित करने की प्रतीक्षा कर रहा है। इस स्थिति में आप SQL सर्वर को ASYNC_NETWORK_IOप्रतीक्षा करते हुए देखेंगे ।
परिणाम से ग्रिड तक पाठ के बजाय परिणाम का उपयोग करके आप इसे कुछ हद तक नियंत्रित कर सकते हैं, क्योंकि SSMS तेजी से पाठ आकर्षित कर सकता है क्योंकि यह ग्रिड आकर्षित कर सकता है, लेकिन आपको यह पता चलेगा कि यह कॉलम की संख्या और शामिल डेटा प्रकारों के आधार पर पठनीयता को प्रभावित कर सकता है। जब एसएसएमएस वास्तव में उस फलक पर परिणाम लिखने का फैसला करता है, तो दोनों प्रभावित होते हैं, जो इस बात पर निर्भर करता है कि आउटपुट बफर कितना पूर्ण है।
जब आपके पास कई कथन हों, और आप बफर को संदेश फलक में आउटपुट परिणाम प्रस्तुत करने के लिए बाध्य करना चाहते हैं, तो आप कथनों के बीच में थोड़ा प्रिंटिंग ट्रिक का उपयोग कर सकते हैं:
RAISERROR('', 0, 1) WITH NOWAIT;लेकिन यह तब मदद नहीं करेगा जब आप SSMS को अधिक तेज़ी से पंक्तियों को प्रस्तुत करने की कोशिश कर रहे हों, जब सभी आउटपुट एक स्टेटमेंट से आ रहे हों।
अधिक सीधे, आप इसे SSMS में कितने परिणाम दे रहे हैं, इसे सीमित करके इसे नियंत्रित कर सकते हैं। मैं अक्सर लोगों को शिकायत करता हूं कि ग्रिड को एक लाख पंक्तियों को वापस करने में कितना समय लगता है। पृथ्वी पर कोई भी SSMS ग्रिड में एक लाख पंक्तियों के साथ क्या करने जा रहा है, मुझे नहीं पता।
कुछ हैक हैं OPTION (FAST 100), जो उन पहले 100 पंक्तियों (या कोई 100 पंक्तियों को प्राप्त करने के लिए अनुकूलित करेंगे यदि कोई बाहरी नहीं है ORDER BY), लेकिन यह शेष पंक्तियों के लिए बहुत धीमी पुनर्प्राप्ति की कीमत पर आ सकता है और एक योजना जो अधिक है समग्र रूप से अक्षम है, इसलिए वास्तव में एक विकल्प IMHO नहीं है।
आपका सवाल एसक्यूएल सेवर प्रति के बारे में नहीं है लेकिन:
क्या इसे नियंत्रित करने का कोई तरीका है?
संक्षिप्त उत्तर :
sqlcmdबजाय ssmsया sqlcmdकी -Modessmsलंबे उत्तर :
बेशक! लेकिन एक नहीं - प्रोब
sqlcmdया के साथ अपनी क्वेरी निष्पादित करें sqlcmd।spidऔर आपको सत्र सेटिंग्स की पूरी सूची मिलती है। sqlcmdसत्र की सेटिंग्स के साथ तुलना करें । यदि कुछ भी क्लिक नहीं करता है - प्रोफाइलर से सभी सत्र सेटिंग्स को अपनी क्वेरी स्क्रिप्ट में कॉपी करें, sqlcmd-mode निष्पादित करें और धीरे-धीरे सेटिंग को स्विच करते हुए आप अपने अपराधी को पाएंगे।सौभाग्य!
Sp_BlitzErik के उत्तर में जोड़ने के लिए, NOT IN ()उप चयन के साथ उदाहरण का उपयोग करें। यह निर्धारित करने के लिए कि कोई आइटम नेस्टेड क्वेरी के परिणाम में है, यह (आम तौर पर) पूरे परिणाम को पुनः प्राप्त करने के लिए आवश्यक है।
इस तरह के प्रश्नों के प्रदर्शन को बेहतर बनाने के लिए एक आसान तरीका यह है कि उन्हें फिर से लिखना एक LEFT OUTER JOINऐसी स्थिति है जहाँ RIGHTपक्ष के लिए स्थिति अशक्त है (आप इसे चारों ओर फ्लिप कर सकते हैं, निश्चित रूप से लेकिन कौन उपयोग करता है RIGHT OUTER JOINS?)। यह परिणामों को तुरंत वापस लौटने के लिए शुरू करने की अनुमति देता है।
WHERE t.x IN (<complex SELECT subquery>)बराबर LEFT JOIN, की जाँच करने से पहले पूरे subselect का मूल्यांकन करने की आवश्यकता होती है LEFT JOIN (<complex SELECT subquery>) AS r ON r.x = t.x .... WHERE r.x IS NULL, तो subquery wil lhave का मूल्यांकन किया जाना चाहिए, (इसलिए जटिल जटिल योजना नहीं है। संस्करण)।
NOT EXISTSलेकिन NOT INप्रश्नों में Oracle । लेकिन आज इसे योजना जनरेटर में त्रुटि के रूप में माना जाना चाहिए