एक सूचकांक या दो?


11

मेरे डेटाबेस में एक टेबल पर निम्नलिखित सूचकांक बनाए गए हैं:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

सर्वर निम्नलिखित 'लापता' सूचकांक का सुझाव दे रहा है:

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

नए सूचकांक बनाने के बजाय सुझाए गए कॉलम को शामिल करने के लिए मौजूदा सूचकांक परिभाषा में संशोधन करना मेरे लिए तर्कसंगत लगता है, जिसे बनाए रखने की आवश्यकता है। एक क्वेरी जो col1 और col2 पर चुनती है वह index1 को प्रभावी रूप से index2 के रूप में उपयोग कर सकती है। क्या मैं सही हूं या मैं शायद कुछ याद कर रहा हूं?

जवाबों:


12

और इसलिए प्रदर्शन ट्यूनिंग और अनुक्रमण रणनीतियों की कला में प्रवेश करता है ...

सुझाए गए स्तंभों को शामिल करने के लिए मौजूदा सूचकांक परिभाषा में संशोधन करना मेरे लिए तर्कसंगत लगता है

मैं आपकी बोली लेने जा रहा हूं और तीसरी इंडेक्स परिभाषा लिखूंगा:

create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

वह CREATE INDEXकथन होना चाहिए जो आपके उद्धृत कथन से मेल खाता हो।

यह बहुत अच्छी तरह से एक विवेकपूर्ण समाधान हो सकता है, लेकिन यह निर्भर करता है । यहाँ कुछ उदाहरण हैं जब मैं कहता हूं कि यह निर्भर करता है।

यदि आपके पास एक सामान्य कार्यभार है जिसमें अधिकतर इस तरह के प्रश्न होते हैं:

select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

तब आपका idx_index1सूचकांक ठोस होगा। पूरी तरह से संकीर्ण, यह एक सूचकांक है जो उस क्वेरी को किसी भी बाहरी डेटा के साथ संतुष्ट नहीं करता है (क्लस्टर इंडेक्स परिभाषा को ध्यान में नहीं रखते हुए, यदि एक बिल्कुल भी)।

लेकिन अगर आपके पास वर्कलोड है जिसमें मुख्य रूप से निम्नलिखित जैसे प्रश्न शामिल हैं:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

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

आपकी सिफारिश के साथ, यह निम्नलिखित की तरह एक प्रश्न के लिए अच्छी तरह से अनुकूल होगा:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

आपकी idx_index3सिफारिश एक कवरिंग इंडेक्स होगी जो उपरोक्त क्वेरी के लिए खोज मानदंडों को संतुष्ट करती है।

मैं जिस बिंदु पर जाने की कोशिश कर रहा हूं, वह अलग-थलग है, इस तरह से हम निश्चित रूप से इसका जवाब नहीं दे सकते हैं। यह सब इस बात पर निर्भर करता है कि आम और लगातार काम का बोझ क्या है। बेशक, आप प्रत्येक नमूना क्वेरी प्रकार को संभालने के लिए हमेशा इन तीनों अनुक्रमितों को परिभाषित कर सकते हैं, लेकिन फिर सवाल में आता है कि रखरखाव के लिए इन सूचकांक को अद्यतन रखने की आवश्यकता होगी (विचार करें: INSERTs, अद्यतन, DELETEs)। यह इंडेक्स का ओवरहेड है।

आपको वर्कलोड को विच्छेदित करने और मूल्यांकन करने की आवश्यकता है, और यह निर्धारित करें कि लाभ कहाँ सबसे अच्छा होगा। यदि पहली नमूना क्वेरी एक सेकंड के दर्जनों बार निष्पादित होने तक सबसे आम है, और तीसरे नमूना क्वेरी की तरह एक बहुत ही अनजान क्वेरी है, तो यह सूचकांक के पत्ती स्तर के पन्नों को ब्लोट के साथ समझ में नहीं आएगा। INCLUDEनॉनवेज कॉलम। यह सब आपके कार्यभार पर निर्भर करता है।

यदि आप विवेकपूर्ण अनुक्रमण रणनीतियों को समझते हैं, और आप अपने सामान्य कार्यभार को समझते हैं, तो उन दोनों को लागू करने से आप क्या कर पाएंगे, जो आपके लिए सबसे अच्छा मार्ग है।


मैं थोड़ी देर के लिए पचाने जा रहा हूं, लेकिन यह एक अच्छा जवाब है। मुझे लगता है कि यह एक टाइपो था कि आपने जो 'इंडेक्स 3' को परिभाषित किया है, उसमें कॉल 3 को एक समानता स्तंभ और एक सम्मिलित कॉलम के रूप में परिभाषित किया गया है?
पौलह

हां :-) अच्छा पकड़। मैंने उसे संपादित किया है।
थॉमस स्ट्रिंगर

यह उल्लेख नहीं करने के लिए कि यदि तालिका में केवल १-६ का हिस्सा है, तो यह १ और २ के सूचकांक में बहुत मूर्खतापूर्ण है और इसमें ३-५ शामिल हैं।
केनेथ फिशर

1
@ केनेथफिशर - वह मूर्खतापूर्ण क्यों होगा? यदि आपके डेटाबेस संरचना और आपके कार्यभार ने इसे वारंट किया है तो यह एक उचित पर्याप्त बात लगती है। उदाहरण के लिए, यदि आपके पास एक क्वेरी है जो कॉलम 1 और 2 के मानों के आधार पर कॉलम 1-5 का चयन करती है, और शायद कॉलम 6 एक nvarchar (अधिकतम) कॉलम है जिसे आप अपने सूचकांक के साथ ब्लोट नहीं करना चाहते हैं।
पौलह

1
@paulH शायद यह सिर्फ मेरी राय है, लेकिन उस बिंदु पर आपने इसमें पर्याप्त कॉलम शामिल किए हैं कि आपके सूचकांक में आपके तालिका में 90 +% स्तंभ हैं, आपने अपने सूचकांक को उस बिंदु तक फूला है जो अतिरिक्त तालिका में जाने के लिए पढ़ा है। स्वयं वह सब महत्वपूर्ण नहीं है। अब निश्चित रूप से कुछ अपवाद हैं .. यदि कर्ल्स 1-5 सभी int हैं और col6 एक varchar (अधिकतम) है तो मैं यह कर सकता हूं। लेकिन सामान्य तौर पर मैं उन बहुत ध्यान से देखेंगे।
केनेथ फिशर

7

आप वास्तव में सही हैं और इस बात की खोज कर चुके हैं कि गायब सूचकांक डीएमवी आदि द्वारा सामने रखे गए "सुझावों" की हमेशा समीक्षा करना डीबीए के लिए क्यों महत्वपूर्ण है ।

विचार करें कि लापता सूचकांक DMV द्वारा प्रस्तुत सुझावों को अलगाव में रखा गया है, जिसका अर्थ है कि SQL सर्वर ने निर्णय लिया कि अनुशंसित संरचना का एक सूचकांक क्वेरी को लाभान्वित करेगा, भले ही अन्य सूचकांक संरचनाएं पहले से मौजूद हों।


3

थोड़े और, थॉमस के उत्तर के निहितार्थों में से एक पर:

उसने कहा:

बेशक, आप प्रत्येक नमूना क्वेरी प्रकार को संभालने के लिए हमेशा इन तीनों अनुक्रमितों को परिभाषित कर सकते हैं, लेकिन फिर सवाल में आता है कि रखरखाव के लिए इन सूचकांक को अद्यतन रखने की आवश्यकता होगी (विचार करें: INSERTs, अद्यतन, DELETEs)। यह इंडेक्स का ओवरहेड है।

तो, एक और बड़ा सवाल यह हो जाता है: तालिका कितनी बार अपडेट की जाती है?

तालिका के पहले उदाहरण पर विचार करें जो लगातार अपडेट किया जाता है, उदाहरण के लिए, ORDERSवेबसाइट उपभोक्ता गतिविधि को दर्शाती एक खुदरा तालिका ... वहां, आप कई अनुक्रमित होने के बारे में ईमानदार रहना चाहते हैं, क्योंकि वे निरंतर अपडेट द्वारा किए गए कार्य को बढ़ाते हैं, और इसलिए लगातार डेटाबेस के प्रदर्शन को प्रभावित करते हैं।

दूसरी ओर, एक तालिका पर विचार करें जो केवल वेबसाइट सेटअप के भाग के रूप में अपडेट की गई है - तालिका को अधिकांश मूल्यों के लिए ONCE अपडेट किया जा रहा है , और मूल्यों को अक्सर जोड़ा जाता है - वहाँ, अपडेट मंदी बहुत विचार नहीं है। एकाधिक इंडेक्स डेटाबेस इंडेक्स को फिर से लोड और रीग्रॉउंड में मंदी कर सकते हैं, लेकिन जब तक वे काफी तेज होते हैं, FEEL FREE: यदि कई इंडेक्स रीड्स को गति देते हैं, तो इसके लिए जाएं।

एक मध्यम मामला एक तालिका हो सकती है जो आम तौर पर केवल रातोंरात बैच प्रक्रिया में अद्यतन की जाती है। वहां, कई इंडेक्स से अपडेट मंदी दिन के प्रदर्शन को प्रभावित नहीं करेगी - वे केवल (1) समय को प्रभावित करेंगे, उस रात बैच के रखरखाव को चलाने के लिए, (2) किसी भी समवर्ती प्रक्रियाओं के प्रदर्शन, और (3) के लिए लिया गया समय सूचकांक पुनर्गठन जैसे डेटाबेस रखरखाव कार्य। इसलिए, जब तक उन 3 एरेनास में प्रक्रियाएं आपके लिए पर्याप्त तेजी से चल रही हैं ... प्रश्नों को गति देने वाले इंडेक्स बनाएं।

HTH ...

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.