2010-03-09 11 views
7

मैंने थोड़ा सा खोज किया है और कोई समान प्रश्न नहीं देखा है, इसलिए यहां जाता है।इंडेक्स का उपयोग कब और किस प्रकार का पता है?

आप कैसे जानते हैं कि किसी तालिका में अनुक्रमणिका कब रखना है? आप इंडेक्स में कौन से कॉलम शामिल करना तय करते हैं? क्लस्टर्ड इंडेक्स कब इस्तेमाल किया जाना चाहिए?

एक सूचकांक कभी select बयान के प्रदर्शन को धीमा कर सकते हैं? इंडेक्स से लाभ उठाने के लिए कितने इंडेक्स बहुत अधिक हैं और टेबल के लिए आपको कितनी बड़ी आवश्यकता है?

संपादित करें:

कॉलम डेटा प्रकारों के बारे में क्या? क्या varchar या datetime पर एक इंडेक्स होना ठीक है?

+0

"क्या यह एक वर्चर्स या डेटाटाइम पर इंडेक्स होना ठीक है?" मेरे पास एक सारणी है जहां क्लस्टर्ड इंडेक्स एक डेटाटाइम पर है (हालांकि हम केवल तारीख भाग का उपयोग कर रहे हैं) क्योंकि तालिका पर सभी प्रश्न प्रारंभ/समाप्ति तिथि जोड़ी तक सीमित हैं और डेटा की चयनशीलता काफी अधिक है यह एक अच्छा विकल्प है। – Tony

उत्तर

3

ठीक है, पहला सवाल आसान है:

जब संकुल अनुक्रमणिका इस्तेमाल किया जाना चाहिए?

हमेशा

। अवधि। बहुत कम, दुर्लभ, किनारे के मामलों को छोड़कर। एक क्लस्टर्ड इंडेक्स प्रत्येक ऑपरेशन के लिए एक टेबल तेज बनाता है। हाँ! ऐसा होता है। पृष्ठभूमि जानकारी के लिए किम ट्रिप के उत्कृष्ट The Clustered Index Debate continues देखें।इस पूरी तरह से पूरा करता बढ़ती

INT पहचान:

  • संकीर्ण
  • स्थिर (कभी नहीं बदलता)
  • अद्वितीय
  • अगर कभी संभव: वह भी संकुल अनुक्रमणिका के लिए उसके मुख्य मानदंड का उल्लेख है - GUID नहीं है। व्यापक पृष्ठभूमि जानकारी के लिए GUID's as Primary Key देखें।

    क्यों संकीर्ण? क्योंकि क्लस्टरिंग कुंजी एक ही तालिका में प्रत्येक गैर-क्लस्टर इंडेक्स के प्रत्येक इंडेक्स पेज में जोड़ा जाता है (यदि आवश्यक हो तो डेटा पंक्ति को वास्तव में देखने में सक्षम होने के लिए)। आप अपनी क्लस्टरिंग कुंजी में VARCHAR (200) नहीं चाहते हैं ....

    अद्वितीय क्यों ?? ऊपर देखें - क्लस्टरिंग कुंजी वह आइटम और तंत्र है जो SQL सर्वर विशिष्ट रूप से डेटा पंक्ति खोजने के लिए उपयोग करता है। यह अद्वितीय होना चाहिए। यदि आप एक गैर-अद्वितीय क्लस्टरिंग कुंजी चुनते हैं, तो SQL सर्वर स्वयं आपकी चाबियों में 4-बाइट अनन्यफायर जोड़ देगा। उस से सावधान रहें!

    अगला: गैर-क्लस्टर सूचकांक। असल में एक नियम है: किसी अन्य तालिका का संदर्भ देने वाली बाल तालिका में कोई भी विदेशी कुंजी अनुक्रमित की जानी चाहिए, इससे जॉइन और अन्य परिचालन तेज हो जाएंगे।

    इसके अलावा, WHERE क्लॉज के किसी भी प्रश्न में एक अच्छा उम्मीदवार है - उन लोगों को चुनें जिन्हें बहुत कुछ किया जाता है। आदेशों के अनुसार ORDER में, WHERE खंडों में दिखाई देने वाले कॉलम पर इंडेक्स रखें।

    अगला: अपने सिस्टम को मापें, अप्रयुक्त या अनुपलब्ध इंडेक्स के बारे में संकेतों के लिए डीएमवी (गतिशील प्रबंधन दृश्य) की जांच करें, और अपने सिस्टम को बार-बार ट्विक करें। यह एक चल रही प्रक्रिया है, आप कभी नहीं किया जाएगा! उन दो डीएमवी (गायब और अप्रयुक्त सूचकांक) पर here for info देखें।

    चेतावनी का एक और शब्द: सूचकांक के ट्रक लोड के साथ, आप कोई भी चयन क्वेरी वास्तव में वास्तव में तेज़ी से कर सकते हैं। लेकिन साथ ही, INSERT, UPDATEs और DELETEs जिन्हें शामिल सभी इंडेक्स को अपडेट करना पड़ सकता है, वे पीड़ित हो सकते हैं। यदि आप केवल कभी चुनते हैं - पागल हो जाओ! अन्यथा, यह एक बढ़िया और नाजुक संतुलन अधिनियम है। आप हमेशा एक प्रश्न को विश्वास से परे ट्विक कर सकते हैं - लेकिन आपके बाकी सिस्टम को ऐसा करने में भुगतना पड़ सकता है। अधिक सूचकांक अपने डेटाबेस नहीं है! कुछ अच्छे सूचकांक रखें, जांचें और देखें कि सिस्टम कैसा व्यवहार करता है, और फिर शायद एक या दो जोड़ सकता है: और फिर देखें: कुल सिस्टम प्रदर्शन उस पर कैसे प्रभावित होता है।

+1

+1 यह नोट करने के लिए कि यह एक सतत प्रक्रिया है और कुछ ऐसा नहीं जो आप एक बार करते हैं। –

+0

दरअसल, हमारा डीबी एसक्यूएल सर्वर और पोस्टग्रेस दोनों है .. तो आपको वहां कार्यान्वयन पर थोड़ा सा विशिष्ट मिला है, लेकिन अन्यथा एक अच्छी व्याख्या है। – Earlz

+0

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

0

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

0

यदि आप कॉलम में मान के आधार पर पूछताछ कर रहे हैं, तो आप शायद इंडेक्स करना चाहते हैं वह कॉलम

यानी

SELECT a,b,c FROM MyTable WHERE x = 1 

आप एक्स पर एक सूचकांक

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

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

अंगूठे का एक नियम के रूप में - अनुक्रमित जोड़ने जब आप अपने आप को कह पाते हैं द्वारा शुरू जहां एक = 123 (इस मामले में, "एक" के लिए एक सूचकांक)। अर्थात जहां और आदेश खंड द्वारा -

0

आप स्तंभ है कि आप चयन और आदेश देने के लिए उपयोग करने पर एक सूचकांक का उपयोग करना चाहिए।

इंडेक्स select बयान धीमा कर सकते हैं उनमें से कई देखते हैं और आप कहां और आदेश कॉलम है अनुक्रमित न की गई पर द्वारा उपयोग कर रहे हैं।

तालिका के आकार के लिए - कई हजार पंक्तियां और ऊपर इंडेक्स उपयोग के लिए वास्तविक लाभ दिखाना शुरू कर देंगे।

यह कहकर, ऐसा करने के लिए स्वचालित उपकरण हैं, और SQL सर्वर में Database Tuning Advisor है जो इससे मदद करेगा।

+0

आईटीडब्ल्यू को अब SQL सर्वर 2005 में "डेटाबेस ट्यूनिंग सलाहकार (डीटीए)" कहा जाता है और –

+0

@marc_s - इसके लिए धन्यवाद। उत्तर अपडेट किया गया। – Oded

1

सामान्य नि प्राथमिक कुंजी (निहित और क्लस्टर के लिए चूक) और प्रत्येक विदेशी कुंजी स्तंभ है

वहाँ एसक्यूएल सर्वर के missing index DMVs

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

1

उन लोगों का जवाब देना जो मैं कह सकता हूं कि प्रत्येक तालिका, चाहे कितनी छोटी हो, कम से कम एक इंडेक्स से हमेशा लाभ उठाएगी क्योंकि कम से कम एक तरीका होना चाहिए जिसमें आप डेटा को देखने में रुचि रखते हैं; अन्यथा इसे क्यों स्टोर करें?

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

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

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

+0

@ टोनी "अन्यथा इसे क्यों स्टोर करें" एक सिस्टम लॉग में क्या है जहां लॉग अक्सर बहुत बार डाला जाता है (कई बार प्रति मिनट) लेकिन डेटा केवल तभी प्राप्त होता है जब कुछ ऐसा होता है जहां लॉग की आवश्यकता होती है (जैसे, प्रत्येक बार महीने या दो) – Earlz

+0

@Earlz: उचित बिंदु, लेकिन जब आप लॉग को देखते हैं तो एक इंडेक्स आपको लॉग तालिका में लाखों पंक्तियों को खोजने में मदद करेगा। मैं देख सकता हूं कि मैं उस कथन के साथ शीर्ष पर थोड़ा सा था :) – Tony

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