2009-06-09 16 views
9

एमएस एसक्यूएल 2000 और 2005 के लिए डीबीए के रूप में, मैं नियमित रूप से विशाल चयन प्रश्न 7-10 या उससे भी अधिक तालिकाओं में शामिल होता हूं। हालांकि, मुझे लगता है कि एक निश्चित बिंदु है जो प्रदर्शन को भुगतना पड़ता है, और क्वेरी को डीबग करना और/या सुधार करना बहुत मुश्किल हो जाता है।एक एसक्यूएल चयन में कितने टेबल "बहुत अधिक" हैं?

तो क्या मुझे "अंगूठे का नियम" है, जब मुझे अन्य क्वेरी विधियों पर विचार करना चाहिए, जैसे प्रारंभिक परिणामों को रखने के लिए temp तालिकाओं? या फिर कोई ऐसा बिंदु है जिसके बाद एसक्यूएल क्वेरी ऑप्टिमाइज़र सबसे अच्छी योजना का पता लगाने का बहुत अच्छा काम नहीं करता है?

+0

इसी प्रकार का प्रश्न: http://stackoverflow.com/questions/793647/is-too-many-left- joins-a-code-smell –

उत्तर

7

कई बार आप सहायक विचारों को बनाकर दृश्य गंध को कम कर सकते हैं, मुझे नहीं लगता कि कितने जोड़ों को बुरा माना जाता है।

प्रक्रियात्मक कोडिंग के विपरीत, छोटे बिट्स और टुकड़ों में एसक्यूएल को तोड़ने से अक्षम प्रश्न हो सकते हैं।

एसक्यूएल ऑप्टिमाइज़र बहुत सारे टेबल में शामिल होने के साथ ठीक काम करेगा, और यदि आप एक कोने केस दबाते हैं, तो आप संकेतों का उपयोग करके शामिल ऑर्डर या स्टाइल निर्दिष्ट कर सकते हैं। हकीकत में मुझे लगता है कि 10 टेबल कहने से अधिक प्रश्न पूछना बहुत दुर्लभ है, लेकिन यह काफी व्यवहार्य है कि यह एक रिपोर्टिंग प्रकार परिदृश्य में हो सकता है।

यदि आप ऐसी स्थिति खोजते हैं जहां आपके पास बहुत सारे शामिल हैं और आपने पाया है कि यह विशेष क्वेरी एक बाधा है और आपके पास सभी सही इंडेक्स हैं, तो आपको शायद रिफैक्टर की आवश्यकता है। हालांकि, ध्यान रखें कि बड़ी संख्या में जॉइन केवल लक्षण हो सकते हैं, इस मुद्दे के रूट कारण नहीं। क्वेरी ऑप्टिमाइज़ेशन के लिए मानक अभ्यास का पालन किया जाना चाहिए (प्रोफाइलर, क्वेरी प्लान, डेटाबेस स्ट्रक्चर, लॉजिक इत्यादि देखें)

एसक्यूएल सर्वर किसी भी तरह से विलय करने के लिए tempdb का उपयोग करता है, इसलिए आमतौर पर रिस्पैक्टर के लिए अस्थायी तालिका बनाने की आवश्यकता नहीं होती है एक एकल चयन क्वेरी।

+0

मैं सहायक विचारों से दूर शर्मिंदा हूं, क्योंकि उनमें अक्सर अतिरिक्त कॉलम, फ़िल्टर हो सकते हैं , तर्क, या जुड़ता है जो एक सामान्य अर्थ में उपयोग करने के लिए "अच्छा" दृश्य लग सकता है, लेकिन एक विशिष्ट क्वेरी के लिए आवश्यक नहीं हो सकता है। मैंने अभी एक जटिल क्वेरी का पुन: उपयोग किया है जो एक अनदेखा कॉलम पर बेकार फ़िल्टर के साथ विशेष रूप से खराब दृश्य का उपयोग कर रहा था। ("जहां निष्क्रिय = 0" लेकिन 16 मिलियन पंक्तियों में से कोई भी वास्तव में इस ध्वज सेट में नहीं था) – BradC

+0

सच है, इस तकनीक को दोबारा प्रतिक्रिया देने के किसी भी प्रकार का दुरुपयोग किया जा सकता है। मुझे लगता है कि आपको कई प्रश्नों की मदद करने के लिए सहायक विचारों पर विचार करना चाहिए (न केवल एक प्रश्न को दोबारा करने के लिए) –

1

यह वास्तव में इस बात पर निर्भर करता है कि आपकी टेबल कितनी बड़ी है, यहां तक ​​कि यदि आप 100 एम रिकॉर्ड हैं तो आप केवल 2 तालिकाओं में शामिल हो जाते हैं, फिर भी यह धीमी प्रक्रिया होगी।

यदि आपके पास तालिका में एक्स रिकॉर्ड हैं और तालिका बी में वाई रिकॉर्ड हैं, यदि आप उन्हें एक साथ जोड़ते हैं, तो आप एक्स * वाई रिकॉर्ड वापस ले सकते हैं, उस स्थिति में स्वैप मेमोरी प्रक्रिया के दौरान उपयोग में होगी , यह धीमा होने वाला है, इसकी तुलना करें, छोटे प्रश्नों में सीपीयू एल 2 कैश का उपयोग किया जाता है जिसमें सबसे अच्छा प्रदर्शन होता है।

हालांकि, यदि आपको लक्ष्य प्राप्त करने के लिए वास्तव में बहुत सारी तालिकाओं में शामिल होने की आवश्यकता है, तो मैं सुझाव दे रहा हूं कि आपके डेटाबेस सामान्यीकृत हो जाएं, 3 सामान्यीकरण अधिकांश परिदृश्यों में वास्तव में अच्छा काम कर रहा है, जानकारी थूकने की कोशिश न करें बहुत अधिक, क्योंकि यह पूछताछ के लिए अक्षम होने के लिए मान्यता प्राप्त है।

हां, यदि आवश्यक हो तो भारी क्वेरी से परिणामों को कैश करने के लिए एक तालिका बनाएं, और आवश्यक होने पर केवल फ़ील्ड अपडेट करें, या दिन में केवल एक बार।

0

मैं 7-10 टेबल में शामिल होने वाले विशाल प्रश्नों को भी देखता हूं, लेकिन जो मैंने देखा है, क्वेरी ऑप्टिमाइज़र को हमेशा सबसे कुशल योजना मिलती है - निश्चित रूप से जटिल मुद्दों के इन प्रकारों में मुझे दिखाई देने वाले सभी प्रदर्शन मुद्दों को आमतौर पर संबंधित किया जाता है किसी अन्य समस्या (जैसे सशर्त WHERE कथन या नेस्टेड उप प्रश्न)

0

ऑप्टिमाइज़र इसे लंबे समय तक चलने से रोकने के लिए स्वयं की समय सीमा निर्धारित करता है। कई तालिकाओं के साथ समस्या यह है कि प्रत्येक व्यक्ति ऑप्टिमाइज़र के मूल्यांकन के लिए संभावित योजनाओं की संख्या को गुणा करता है (वास्तव में इसमें शामिल होने की संख्या है, प्रति टेबल नहीं)। कुछ बिंदु पर ऑप्टिमाइज़र समय से बाहर चला जाता है और अब तक की सबसे अच्छी योजना का उपयोग करेगा, जो कि बहुत खराब हो सकता है।

तो यह बिंदु कहां है? खैर, यह बहुत परिस्थितिपूर्ण है, और 2005 2000 से काफी बेहतर है, लेकिन एसक्यूएल सर्वर 2000 के लिए अंगूठे का मेरा सामान्य नियम 4-8 है और SQL सर्वर 2005 के लिए 6-16 है।

0

अन्य चर शामिल हैं जिनमें अधिक है जैसे समग्र क्वेरी योजना और प्रदर्शन पर महत्वपूर्ण प्रभाव, मेरे अनुभव में,: प्रत्येक के लिए

  • इनपुट पंक्ति में गिना जाता है में शामिल होने के ऑपरेटर
  • कैसे कुशलतापूर्वक इनपुट डेटा पहली जगह
  • में प्राप्त किए जा सकें कॉलम का आकार और प्रकार शामिल हो रहा है (उदाहरण के लिए रूपांतरण, शून्यता टाइप करें)

आपके पास एक क्वेरी में केवल दो टेबल एक साथ शामिल हो सकते हैं, लेकिन यदि एक कुंजी कॉलम एक GUID है और दूसरा GUID का वर्चर प्रतिनिधित्व है, तो आपके पास कहीं भी कोई अनुक्रमणिका नहीं है, और तालिकाएं 2 मिलियन पंक्तियां हैं प्रत्येक, तो आपको शायद बहुत खराब प्रदर्शन मिलेगा।

मैंने पहले 10+ जोड़ों के साथ रिपोर्टिंग प्रश्नों को कोड किया है, और विदेशी कुंजी कॉलम पर कुछ गैर-क्लस्टर इंडेक्स का न्यायसंगत उपयोग आमतौर पर योजना पर सबसे बड़ा लाभ होता है।

+0

यदि आपके पास बहुत कुछ है तो SQL सर्वर ऑप्टिमाइज़र आपके सभी जोड़ों को नहीं देखेगा, इसलिए यदि आप कुछ जुड़ते हैं आपकी क्वेरी में दूसरों की तुलना में अधिक मदद करेगा, सूची में उन्हें स्थानांतरित करने का एक फायदा है। – Joe

संबंधित मुद्दे