से तालिका चर का उपयोग कर रहा है क्या मैं यह मानने के लिए सुरक्षित हूं कि मैंने अस्थायी तालिका लिखने के लिए tempdb का उपयोग करके प्रक्रियाओं को संग्रहीत किया है, बेहतर प्रदर्शन पाने के लिए मैं इन्हें तालिका चर में स्विच करने से बेहतर होगा?टेम्पलेट टेबल
टेम्पल टेबल प्रदर्शन में बेहतर हैं। यदि आप टेबल वैरिएबल का उपयोग करते हैं और वेरिएबल में डेटा बहुत बड़ा हो जाता है, तो SQL सर्वर वेरिएबल को स्वचालित रूप से एक temp तालिका में परिवर्तित करता है।
यह आपके द्वारा किए जाने वाले प्रयासों पर लगभग हर डेटाबेस से संबंधित प्रश्न की तरह निर्भर करता है। इसलिए बिना किसी जानकारी के जवाब देना मुश्किल है।
तो मेरा जवाब है, इसे आज़माएं और निष्पादन योजना पर नज़र डालें। सबसे कम लागत के साथ सबसे तेज़ तरीका का प्रयोग करें।
क्या शीर्ष पर मेरी टिप्पणी समझ में आती है और क्या मुझे स्विच करना चाहिए? –
यह कहना मुश्किल है, स्विच करना या नहीं। यदि आप एक टेबल वैरिएबल वापस करना चाहते हैं और आपके ऑपरेशन दोनों तरीकों से तेज़ हैं, तो हाँ मैं स्विच करूंगा। आपको वास्तव में इसे आजमा देना चाहिए। उदाहरण के लिए, पिछले हफ्ते मैंने एक क्वेरी अनुकूलित की जो इतनी धीमी हो गई। 20 घंटे पहले, अब 2 मिनट। मैं केवल एक तालिका चर से एक temp तालिका में बदल दिया। लौटाया गया डेटा बड़ा नहीं था, केवल 2000 पंक्तियां, लेकिन कई संचालन और फ़िल्टर। – dknaack
"यदि आप तालिका वैरिएबल का उपयोग करते हैं और वेरिएबल में डेटा बहुत बड़ा हो जाता है, तो SQL सर्वर वेरिएबल को स्वचालित रूप से एक temp तालिका में परिवर्तित करता है।" यह कथन पूरी तरह झूठा है। –
के रूप में वहाँ कम "सेटअप समय" है, क्योंकि वस्तु केवल स्मृति में है @Table तेजी से हो सकता है।
@Tables के पास बहुत सारे कैच हैं।
आपके पास @Table पर प्राथमिक कुंजी हो सकती है लेकिन इसके बारे में है। कॉलम के संयोजन के लिए क्लस्टर नॉनक्स्टर्ड अन्य इंडेक्स संभव नहीं हैं।
यदि आपकी तालिका में कोई वास्तविक डेटा वॉल्यूम शामिल है (अधिक से अधिक 200 शायद 1000 पंक्तियां) तो तालिका तक पहुंच धीमी हो जाएगी। विशेष रूप से जब आपके पास शायद उस पर एक उपयोगी अनुक्रमणिका नहीं होगी।
# टेबल्स प्रो में दर्द होता है क्योंकि उन्हें डीबगिंग के दौरान गिराया जाना चाहिए, उन्हें बनाने में अधिक समय लगता है। और वे सेटअप के लिए अधिक समय लेते हैं क्योंकि आपको दूसरे चरण के रूप में इंडेक्स जोड़ने की आवश्यकता होती है। लेकिन अगर आपके पास बहुत सारे डेटा हैं तो इसके #tables हर बार।
यहां तक कि जिन मामलों में आपके पास तालिका में डेटा की 100 पंक्तियां कम हैं, तब भी आप #Tables का उपयोग करना चाहेंगे क्योंकि आप तालिका पर एक उपयोगी अनुक्रमणिका बना सकते हैं।
संक्षेप में मैं सरल proc आदि करते समय आसानी से @Tables का उपयोग करता हूं लेकिन कुछ भी करने की आवश्यकता है जो #Table होना चाहिए।
मैं इस फैबिल पर भी विश्वास करता था, जब तक कि मैं हाल ही में एक प्रश्न की सफाई नहीं कर रहा था (और आखिरी चीजों में से एक) सटीक वही क्वेरी (एक ही पैराम का उपयोग करके कई बार चलने का परीक्षण किया गया) 5 सेकंड में वापस ' TempTable' बनाम 16 सेकंड '@ tableVar' का उपयोग कर – Jason
@Tables के पास कोई आंकड़े नहीं हैं इसलिए निष्पादन योजना में अधिक अनुमान लगाना शामिल है। इसलिए 1000-आश पंक्तियों की अनुशंसित ऊपरी सीमा। # टेबल्स के आंकड़े हैं लेकिन इन can be cached इनवोकेशन के बीच हैं। यदि हर बार एसपी चलाने पर आपकी कार्डिनिटी काफी भिन्न होती है तो आप हर बार REBUILD और RECOMPILE करना चाहते हैं। यह निश्चित रूप से एक उपरि है, लेकिन एक जो बकवास योजना की लागत के खिलाफ संतुलित होना चाहिए।
दोनों प्रकार IO to TempDB करेंगे।
तो नहीं, @ टेबल्स एक पैनसिया नहीं हैं।
अस्थायी तालिकाओं में कितने रिकॉर्ड होंगे, आपके सर्वर कॉन्फ़िगरेशन जैसे तालिका चर के रूप में tempdb पर धक्का दिया जा सकता है। http://blogs.msdn.com/b/sqlserverstorageengine/archive/2008/03/30/sql-server-table-variable-vs-local- समकालीन-table.aspx – Kane
डेटा भिन्न होता है, लेकिन यह एक अच्छा बिंदु है । यदि एक तालिका चर डेटा की थोड़ी मात्रा के साथ अधिक प्रदर्शनशील होगा, तो मैं इसे चालू कर दूंगा। –
संभावित डुप्लिकेट [SQL सर्वर में एक temp तालिका और तालिका चर के बीच क्या अंतर है?] (Http://stackoverflow.com/questions/27894/whats-the-difference-between-a-temp-table-and-table -वर्तनीय-इन-एसक्यूएल-सर्वर) या यह: http: // stackoverflow।कॉम/प्रश्न/69 9 1511/एसक्यूएल-सर्वर-टेम्प-टेबल-बनाम-टेबल-वेरिएबल और शायद अधिक – gbn