क्लस्टरर्ड इंडेक्स स्कैन के बजाय क्लस्टर्ड इंडेक्स सीक पाने के लिए मुझे क्या करना चाहिए?

Question

मुझे SQL सर्वर 2005 में एक संग्रहीत प्रक्रिया मिली है और जब मैं इसे चलाता हूं और मैं अपनी निष्पादन योजना को देखता हूं तो मुझे लगता है कि यह क्लस्टर्ड इंडेक्स स्कैन कर रहा है, और इसकी कीमत 84% है। मैंने पढ़ा है कि क्लस्टर्ड इंडेक्स पाने के लिए मुझे कुछ चीजों को संशोधित करना होगा, लेकिन मुझे नहीं पता कि क्या संशोधित करना है।

मैं इसके साथ किसी भी मदद की सराहना करता हूं।

धन्यवाद,

ब्रायन

Answer 1

डब्ल्यू/ओ किसी भी विवरण को अनुमान लगाने में मुश्किल है कि समस्या क्या है, और यहां तक ​​कि कोई समस्या भी है या नहीं। एक खोज के बजाय स्कैन की पसंद कई कारकों से प्रेरित की जा सकती है:

• क्वेरी पूरी तालिका को कवर करने वाले परिणाम सेट को व्यक्त करती है। अर्थात। क्वेरी एक साधारण SELECT * FROM <table> है। यह एक मामूली मामला है जो क्लस्टर इंडेक्स स्कैन द्वारा पूरी तरह से कवर किया जाएगा, किसी और चीज पर विचार करने की आवश्यकता नहीं है।
• अनुकूलक को विकल्प दिया गया है:
  • क्वेरी पूरे तालिका के एक सबसेट को व्यक्त करता है, लेकिन छानने विधेय कॉलम कि क्लस्टर कुंजी का हिस्सा नहीं हैं पर है और वहाँ उन स्तंभों पर कोई गैर clustred अनुक्रमित रहे हैं या तो। यह पूर्ण स्कैन के अलावा कोई वैकल्पिक योजना नहीं है।
  • क्वेरी फ़िल्टरिंग क्लस्टर इंडेक्स कुंजी में कॉलम पर पूर्वानुमानित करती है, लेकिन वे SARGable नहीं हैं। फ़िल्टरिंग भविष्यवाणी को आमतौर पर इसे सार्ज करने के लिए फिर से लिखना होगा, उचित पुनर्लेख केस से मामले पर निर्भर करता है। निहित रूपांतरण नियमों के कारण एक और सूक्ष्म समस्या दिखाई दे सकती है, उदाहरण के लिए। फ़िल्टरिंग अनुमान WHERE column = @value है लेकिन कॉलम VARCHAR (Ascii) है और @value NVARCHAR (यूनिकोड) है।
  • क्वेरी में SARGale फ़िल्टरिंग क्लस्टर कुंजी में कॉलम पर भविष्यवाणी करती है, लेकिन बाएं कॉलम फ़िल्टर नहीं किया जाता है। अर्थात। क्लस्टेड इंडेक्स कॉलम (foo, bar) पर है लेकिन WHERE क्लॉज bar अकेले है।
• अनुकूलक स्कैन चुनता है।
  • जब विकल्प एक गैर क्लस्टर सूचकांक तो स्कैन (या सीमा की तलाश) है, लेकिन चुनाव एक की कमी के कारण क्लस्टर सूचकांक का उपयोग करने के आमतौर परindex tipping point करने के लिए नीचे ट्रैक किए गए कारण हो सकता है गैर क्लस्टर क्वेरी प्रक्षेपण के लिए सूचकांक कवरेज। ध्यान दें कि यह आपका प्रश्न नहीं है, क्योंकि आप क्लस्टर्ड इंडेक्स की अपेक्षा करते हैं, न कि गैर-क्लस्टेड इंडेक्स की तलाश करें (प्रश्न को मानना ​​100% सटीक और दस्तावेज है ...)
  • कार्डिनालिटी अनुमान। क्वेरी लागत अनुमान क्लस्टर इंडेक्स कुंजी (ओं) आंकड़ों पर आधारित होता है जो परिणाम की कार्डिनालिटी का अनुमान प्रदान करते हैं (यानी। कितनी पंक्तियां मिलेंगी)। एक साधारण प्रश्न पर ऐसा नहीं हो सकता है, क्योंकि किसी खोज या श्रेणी की तलाश के लिए कोई अनुमान स्कैन के लिए एक से कम होगा, इससे कोई फर्क नहीं पड़ता कि आंकड़े कैसे हैं, लेकिन जटिल क्वेरी पर, एकाधिक तालिकाओं में शामिल होने और फ़िल्टर के साथ , चीजें अधिक जटिल हैं और योजना एक स्कैन शामिल कर सकती है जहां एक खोज की उम्मीद थी क्योंकि क्वेरी ऑप्टिमाइज़र उस योजना का चयन कर सकता है जिस पर पर्यवेक्षक की उम्मीद के अनुसार शामिल मूल्यांकन आदेश को उलट दिया जाता है। रिवर्स ऑर्डर विकल्प सही हो सकता है (अधिकतर बार) या समस्याग्रस्त हो सकता है (आमतौर पर आंकड़ों को अप्रचलित या पैरामीटर स्नीफिंग के कारण)।
  • एक आदेश गारंटी। एक स्कैन एक गारंटीकृत क्रम में परिणाम देगा और निष्पादन पेड़ पर उच्च तत्व इस आदेश से लाभ उठा सकते हैं (उदाहरण के लिए। एक प्रकार या स्पूल को समाप्त किया जा सकता है, या हैश/नेस्टेड जॉइन के बजाय विलय में शामिल किया जा सकता है)। एक स्पष्ट रूप से धीमी पहुंच पथ चुनने के परिणामस्वरूप कुल मिलाकर क्वेरी लागत बेहतर है।

ये कुछ जल्दी संकेत क्यों संकुल अनुक्रमणिका स्कैन मौजूद हो सकता है जब एक संकुल अनुक्रमणिका की तलाश की उम्मीद है कर रहे हैं। सवाल बेहद सामान्य है और 8 गेंद पर भरोसा करने के अलावा, जवाब 'क्यों' देना असंभव है। अब यदि मैं आपका प्रश्न सही तरीके से प्रलेखित और सही ढंग से व्यक्त करने के लिए लेता हूं, तो क्लस्टर सूचकांक की तलाश करने का अर्थ है इसका मतलब है कि आप क्लस्टर किए गए कुंजी मान के आधार पर एक अद्वितीय रिकॉर्ड खोज रहे हैं। इस मामले में समस्या WHERE क्लॉज की SARGability के साथ होना चाहिए।

Answer 2

क्वेरी तालिका में पंक्तियों का एक निश्चित प्रतिशत की तुलना में अधिक incldues हैं, अनुकूलक, बजाय एक की तलाश के स्कैन करने के लिए चुनाव किया जाएगा, क्योंकि यह भविष्यवाणी की है कि कहीं भी होगी उस मामले में कम डिस्क आईओ की आवश्यकता होती है (एक खोज के लिए, इसे प्रत्येक पंक्ति के लिए सूचकांक में एक स्तर IO प्रति स्तर की आवश्यकता होती है), जबकि स्कैन के लिए पूरी तालिका में केवल एक डिस्क आईओ प्रति पंक्ति होती है।

तो यदि बी हैं, तो बी-पेड़ इंडेक्स में 5 स्तर कहें, तो यदि तालिका तालिका में 20% से अधिक पंक्तियां उत्पन्न करेगी, तो प्रत्येक तालिका के लिए 5 आईओ बनाने की तुलना में पूरी तालिका को पढ़ने के लिए सस्ता है 20% पंक्तियों में से ...

क्या आप प्रक्रिया में इस चरण द्वारा लौटाई गई पंक्तियों की संख्या को कम करने के लिए क्वेरी के आउटपुट को थोड़ा और संकीर्ण कर सकते हैं? इससे स्कैन पर तलाश करने में मदद मिलेगी।