क्या किसी पहचान स्तंभ पर अनुक्रमणिका को अस्पष्ट किया जाना चाहिए?


19

पहचान कॉलम वाली तालिका के लिए, पहचान कॉलम के लिए एक संकुल या गैर-संकुल पीके / अद्वितीय सूचकांक बनाया जाना चाहिए?

कारण प्रश्नों के लिए अन्य सूचकांक बनाए जाएंगे। एक क्वेरी जो एक गैर-अनुक्रमित इंडेक्स (एक ढेर पर) का उपयोग करती है और जो कॉलम इंडेक्स द्वारा कवर नहीं किए जाते हैं, वे कम तार्किक I / O (LIO) का उपयोग करेंगे क्योंकि कोई अतिरिक्त क्लस्टर इंडेक्स बी-ट्री स्टेप नहीं हैं?

create table T (
  Id int identity(1,1) primary key, -- clustered or non-clustered? (surrogate key, may be used to join another table)
  A .... -- A, B, C have mixed data type of int, date, varchar, float, money, ....
  B ....
  C ....
  ....)

create index ix_A on T (A)
create index ix_..... -- Many indexes can be created for queries

-- Common query is query on A, B, C, ....
select A, B 
from T 
where A between @a and @a+5 -- This query will have less LIO if the PK is non-clustered (seek)

select A, B, C
from T 
where B between @a and @a+5 

....

पहचान कॉलम पर संकुल PK अच्छा है क्योंकि:

  1. यह एकाकी रूप से वृद्धि करता है इसलिए सम्मिलित करते समय कोई पृष्ठ विभाजित नहीं होता है। यह कहा जाता है कि एक बल्क इंसर्ट एक ढेर (नॉनक्लेस्टेड) ​​टेबल पर जितना तेज हो सकता है

  2. यह संकीर्ण है

हालांकि, क्या प्रश्न में दिए गए प्रश्नों को बिना क्लस्टर किए तेजी से खत्म किया जाएगा?

** अद्यतन: ** क्या होगा यदि Idअन्य तालिकाओं का एफके है और यह कुछ प्रश्नों में शामिल हो जाएगा?


3
यह बेहतर या बुरा नहीं है, यह निर्भर करता है।
हारून बर्ट्रेंड

1
@ypercube लिंक kejser.org/clustered-indexes-vs-heaps ने कहा कि गैर-सीआई के पास LIO कम होगा।
u23432534

2
मैंने अतीत में लेख पढ़ा है और यह निश्चित रूप से इंगित करता है कि एक गुच्छेदार सूचकांक के लिए मामले हैं और एक ढेर के लिए मामले हैं। यह सब काला या सफेद नहीं है।
ypercube y

4
मुझे यकीन नहीं है कि @ypercube को आपकी प्रतिक्रिया मिस्टर केसर द्वारा उद्धृत किसी भी मापदंड से संतुष्ट करती है - कम से कम साझा किए गए विवरणों के साथ। अपने वर्तमान रूप में, मुझे वास्तव में यकीन नहीं है कि यह एक उपयोगी उत्तर उत्पन्न करने वाला है क्योंकि इसे लगभग हर एक परिदृश्य को कवर करना होगा - जो कि आपके द्वारा उद्धृत ब्लॉग पोस्ट में पहले से ही किया गया है। यदि आप अपने विशिष्ट परिदृश्य के बारे में अधिक जानकारी प्रदान कर सकते हैं तो शायद पोस्ट में कुछ ज्ञान लागू किया जा सकता है।
swashheck

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

जवाबों:


16

डिफ़ॉल्ट रूप से पीके को क्लस्टर किया जाता है और ज्यादातर मामलों में, यह ठीक है। हालांकि, कौन सा प्रश्न पूछा जाना चाहिए:

  • क्या मेरे पीके का क्लस्टर किया जाना चाहिए?
  • मेरे क्लस्टर किए गए अनुक्रमणिका के लिए कौन सा कॉलम (कुंजी) सबसे महत्वपूर्ण होगा?

PK और क्लस्टर इंडेक्स 2 अंतर चीजें हैं:

  • पीके एक बाधा है। पीके का उपयोग विशिष्ट रूप से पंक्तियों की पहचान करने के लिए किया जाता है, लेकिन भंडारण की कोई धारणा नहीं है। हालाँकि डिफ़ॉल्ट रूप से (SSMS में), यह एक अनूठे क्लस्टर इंडेक्स द्वारा लागू किया जाता है, यदि क्लस्टर्ड इंडेक्स अभी तक मौजूद नहीं है।
  • क्लस्टर इंडेक्स एक विशेष प्रकार का इंडेक्स है जो लीफ लेवल पर पंक्ति डेटा को स्टोर करता है, जिसका अर्थ है कि यह हमेशा कवर होता है। सभी कॉलम चाहे वे कुंजी का हिस्सा हों या न हों, पत्ती के स्तर पर संग्रहीत होते हैं। यह अद्वितीय होना जरूरी नहीं है, जिस स्थिति में क्लस्टर कुंजी के लिए एक विशिष्ट (4 बाइट्स) जोड़ा जाता है।

अब हम 2 प्रश्न समाप्त करते हैं:

  • मैं अपनी तालिका (PK) में विशिष्ट रूप से पंक्तियों की पहचान कैसे करना चाहता हूं
  • मैं इसे एक इंडेक्स (क्लस्टर्ड इंडेक्स) के पत्ते के स्तर पर कैसे संग्रहीत करना चाहता हूं

यह इस बात पर निर्भर करता है:

  • आप अपना डेटा मॉडल डिज़ाइन करते हैं
  • आप अपने डेटा को क्वेरी करते हैं और आप अपने प्रश्नों को लिखते हैं
  • आप अपना डेटा डालें या अपडेट करें
  • ...

सबसे पहले, आपको एक क्लस्टर इंडेक्स की आवश्यकता है? यदि आप बल्क इंसर्ट करते हैं, तो अनऑर्डर किए गए डेटा को HEAP (बनाम क्लस्टर में डेटा ऑर्डर किया गया) को स्टोर करना अधिक कुशल है। यह RID (पंक्ति पहचानकर्ता, 8 बाइट्स) का उपयोग विशिष्ट रूप से पंक्तियों की पहचान करने और पृष्ठों पर संग्रहीत करने के लिए करता है।

गुच्छित सूचकांक एक यादृच्छिक मूल्य नहीं होना चाहिए। पत्ता स्तर का डेटा इंडेक्स कुंजी द्वारा संग्रहीत और ऑर्डर किया जाएगा। इसलिए विखंडन या पृष्ठ विभाजन से बचने के लिए इसे लगातार बढ़ना चाहिए। यदि यह पीके द्वारा हासिल नहीं किया जा सकता है, तो आपको एक अन्य कुंजी को एक गुच्छेदार उम्मीदवार के रूप में विचार करना चाहिए। पहचान योग्य स्तंभों, अनुक्रमिक GUID या यहां तक ​​कि सम्मिलन की तारीख जैसे कुछ अनुक्रम अनुक्रमिक दृष्टिकोण से ठीक है क्योंकि सभी पंक्तियों को अंतिम पत्ती पृष्ठ पर जोड़ा जाएगा। दूसरी ओर, जबकि अद्वितीय पहचानकर्ता आपके व्यवसाय की जरूरतों के लिए पीके के रूप में उपयोगी हो सकते हैं, उन्हें क्लस्टर नहीं किया जाना चाहिए (वे बेतरतीब ढंग से आदेशित / उत्पन्न होते हैं)।

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

क्लस्टर इंडेक्स कुंजी उन सभी कॉलमों से बनी है, जिन्हें आप इंडेक्स करना चाहते हैं। यदि इस पर कोई अद्वितीय बाधा नहीं है (डुप्लिकेट के लिए वृद्धिशील मूल्य, शून्य अन्यथा) तो एक अद्वितीय स्तंभ (4 बाइट्स) जोड़ा जाता है। इस सूचकांक कुंजी को आपके सभी गैर-अनुक्रमित अनुक्रमितों के पत्ती स्तर पर प्रत्येक पंक्ति के लिए एक बार संग्रहीत किया जाएगा। उनमें से कुछ को इंडेक्स ट्री (बी-ट्री) की जड़ और पत्ती के स्तर के बीच मध्यवर्ती स्तरों (शाखा) में कई बार संग्रहीत किया जाएगा। यदि कुंजी बहुत बड़ी है, तो सभी गैर-संकुल सूचकांक बड़े हो जाएंगे, अधिक संग्रहण और अधिक IO, CPU, मेमोरी की आवश्यकता होगी ... यदि आपके पास नाम + जन्मतिथि + देश पर PK है, तो यह बहुत महत्वपूर्ण है कि यह कुंजी अच्छा उम्मीदवार नहीं है। यह एक गुच्छेदार सूचकांक के लिए बहुत बड़ा है। NEWSEQUENTIALID () का उपयोग करके अद्वितीय पहचानकर्ता को आमतौर पर एक संकीर्ण कुंजी (16 बाइट्स) के रूप में नहीं माना जाता है, हालांकि यह अनुक्रमिक है।

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

गैर क्लस्टर किए गए अनुक्रमणिका में हमेशा क्लस्टर की गई कुंजी होगी। हालाँकि, यदि अनुक्रमित कॉलम (+ कुंजी कॉलम) कवर कर रहे हैं, तो क्लस्टर इंडेक्स में कोई भी महत्वपूर्ण लुकअप नहीं होगा। मत भूलो कि तुम भी शामिल कर सकते हैं और कहाँ एक गैर संकुल सूचकांक के लिए। (समझदारी से इस्तेमाल करो)

क्लस्टर किया गया अनुक्रमणिका अद्वितीय होना चाहिए और जितना संभव हो उतना संकीर्ण होना चाहिए, गुच्छित अनुक्रमणिका समय के साथ परिवर्तित नहीं होनी चाहिए और इसे वृद्धिशील रूप से सम्मिलित किया जाना चाहिए।

अब कुछ एसक्यूएल लिखने का समय है जो तालिका, क्लस्टर किए गए और गैर-अनुक्रमित सूचकांक और बाधाओं का निर्माण करेगा।

यह सभी सिद्धांत है क्योंकि हम आपके डेटा मॉडल और उपयोग किए गए डेटाैट (ए और बी) को नहीं जानते हैं।


11

एक पहचान स्तंभ पर प्राथमिक कुंजी (पीके) के साथ एक तालिका के लिए, यह डिफ़ॉल्ट रूप से क्लस्टर किया जाएगा। क्या यह गैर-स्पष्ट के रूप में बेहतर हो सकता है?

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

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

क्या प्रश्न में दिए गए प्रश्न क्लस्टर्ड सेट किए बिना तेज़ हो जाएंगे?

हां, लेकिन कैविट्स के साथ।

RID लुकअप वास्तव में की लुक्स की तुलना में अधिक कुशल हैं। यहां तक ​​कि अगर सभी आवश्यक पृष्ठ मेमोरी में हैं (एक इंडेक्स के ऊपरी स्तरों के लिए बहुत संभावना है), एक सीपीयू लागत है जो क्लस्टर इंडेक्स बी-ट्री को नेविगेट करने से जुड़ी है। परिणामस्वरूप, SQL सर्वर आमतौर पर CPU समय की प्रति यूनिट मुख्य लुकअप की तुलना में कई अधिक RID लुकअप कर सकता है।

चेतावनियां

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

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

जॉइन के बारे में सवाल के अपडेट के बारे में, निष्पादन योजनाओं पर क्लस्टर इंडेक्स को खोने के प्रभाव का आकलन करने से ऊपर के विश्लेषण का हिस्सा बनेगा। यदि नेस्टेड लूप्स जॉइन का उपयोग किया जाता है, तो ज्वाइन की पर क्लस्टर किए गए इंडेक्स को रखना बहुत सुविधाजनक है क्योंकि पंक्ति से सभी कॉलम तुरंत लुकअप के बिना उपलब्ध हैं।

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


8

वास्तव में, आपको एक Clustered Index की जरूरत नहीं है और न ही एक प्राथमिक Key बनाने की है, क्योंकि Unique Indexes और Non-Unique Indexes काम को संभाल सकते हैं। SQL सर्वर ने कम से कम 1.1 संस्करण के बाद से क्लस्टर इंडेक्स का समर्थन किया है, लेकिन प्राथमिक कुंजी सिर्फ एक "अवधारणा" थी जिसे प्रोग्रामर ने एक अद्वितीय इंडेक्स को परिभाषित करके लागू किया था।

लेकिन ऐसा लगता है कि प्राथमिक कुंजी और क्लस्टर इंडेक्स दोनों ही अधिकांश डेटाबेस में मूल्यवान अवधारणाएं हैं।

नीचे दिए गए प्रदर्शन के रूप में कुछ अनुक्रमण विकल्पों के आंशिक विवरण को देखने के लिए SQL सर्वर दस्तावेज़ीकरण देखें।

गुच्छित सूचकांक: https://msdn.microsoft.com/en-us/library/ms190457.aspx

  • क्लस्टर किए गए अनुक्रमणिका तालिका में डेटा पंक्तियों को सॉर्ट और संग्रहीत करते हैं या उनके प्रमुख मूल्यों के आधार पर देखते हैं। ये सूचकांक परिभाषा में शामिल किए गए कॉलम हैं।
  • प्रति तालिका केवल एक संकुल सूचकांक हो सकता है

प्राथमिक कुंजी: https://msdn.microsoft.com/en-us/library/ms190457.aspx

  • एक तालिका में केवल एक प्राथमिक कुंजी बाधा हो सकती है।

  • PRIMARY KEY बाधा के भीतर परिभाषित सभी स्तंभों को नॉट NULL के रूप में परिभाषित किया जाना चाहिए।

  • प्राथमिक कुंजी एक क्लस्टर इंडेक्स (डिफ़ॉल्ट यदि कोई क्लस्टर इंडेक्स नहीं है) या गैर-क्लस्टर इंडेक्स के रूप में बनाई जा सकती है।

अद्वितीय सूचकांक: https://msdn.microsoft.com/en-us/library/ms187019.aspx

  • जब आप एक UNIQUE बाधा बनाते हैं, तो एक अद्वितीय गैर-अनुक्रमित सूचकांक डिफ़ॉल्ट रूप से एक UNIQUE बाधा को लागू करने के लिए बनाया जाता है।

  • यदि तालिका के लिए पहले से मौजूद क्लस्टर नहीं है, तो आप एक UNIQUE क्लस्टर किए गए अनुक्रमणिका को निर्दिष्ट कर सकते हैं।

इसका मतलब यह है कि क्लस्टर्ड इंडेक्स और प्राथमिक कुंजी के बारे में आपका प्रश्न वास्तव में निम्नलिखित कुछ मुद्दों के बारे में है। कृपया ध्यान दें कि प्रत्येक तालिका एक ही अनुक्रमण योजना से लाभान्वित नहीं होती है।

प्राथमिक कुंजी को क्लस्टर किए गए इंडेक्स से अलग होने पर मुझे कब लाभ होगा?

शायद जब क्लस्टर इंडेक्स विस्तृत है (उदाहरण के लिए, पाठ्य सूचना के 5 कॉलम, लेकिन प्राथमिक कुंजी छोटी है (INT या BIGINT), जैसे कि आप वर्णन कर रहे हैं।

  • एक विस्तृत क्लस्टर इंडेक्स आपको प्रश्नों के एक सबसेट के लिए इंडेक्स से पंक्तियों को जल्दी से चुनने की अनुमति देगा, जो क्लस्टर इंडेक्स ( तालिका के रूप में भी जाना जाता है ) से धारावाहिक उत्तर प्रदान करते हैं । उदाहरण के लिए, 5-कॉलम वाला क्लस्टर इंडेक्स कॉलम C1, C2, C3, C4, C5 या C1, C2, C3, C4 को स्कैन करने का समर्थन करेगा।
  • नोट: यदि पंक्तियाँ बड़ी थीं, तो इससे आपको पंक्तियों के क्रमिक सेट का चयन करने पर कुछ गति लाभ मिल सकते हैं, खासकर यदि तालिका के अन्य कॉलम नियमित रूप से परिणाम सेट में शामिल हैं।
  • उस स्थिति में आप अन्य तालिकाओं में पंक्तियों को बाध्य करने के लिए एक विदेशी कुंजी के रूप में आवश्यक मूल्य की आपूर्ति करने के लिए संदर्भात्मक अखंडता के लिए प्राथमिक कुंजी का उपयोग कर सकते हैं । पीके छोटा है और इस प्रकार संदर्भित तालिका के आकार पर एफके एक छोटी हिट है।
  • हालाँकि, ध्यान दें कि किसी तालिका पर बनाए गए अनुक्रमणिका जिसमें Clustered अनुक्रमणिका है, इस तालिका पर आपके द्वारा बनाए गए अन्य अनुक्रमणिकाओं में सभी क्लस्टर स्तंभों को शामिल करेगी। एक विस्तृत संकुल सूचकांक उस तालिका पर सभी गैर-संकुल सूचकांकों के आकार का विस्तार करेगा।

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

  • यदि आपके पास एक छोटी प्राथमिक कुंजी (INT या BIGINT) है और यह Clustered Index है, तो क्लस्टर कॉलम का ओवरहेड अपेक्षाकृत छोटा है। हालाँकि इस मामले में क्लस्टर्ड प्राइमरी की भी इस टेबल पर हर इंडेक्स में मौजूद होगी, लेकिन ऊपर उल्लिखित वाइड क्लस्टर की तुलना में इसकी कीमत कम है।

  • यह प्राथमिक कुंजी क्लस्टर इंडेक्स आमतौर पर सीधे कई पंक्तियों का चयन करने के लिए एक आसान रास्ता प्रदान नहीं करेगा।

  • अब जब आपने एक क्लस्टर प्राथमिक कुंजी बना ली है, तो उन अन्य स्तंभों के बारे में जो आप एक बार क्लस्टर सूचकांक में शामिल करने की योजना बना रहे थे ?

  • स्तंभ C1, C2, C3, C4, C5 के विस्तृत खोज मापदंड को अनुक्रमणित करने के लिए आवश्यकतानुसार एक विशिष्ट (या गैर-अद्वितीय) अनुक्रमणिका बनाएँ। इस "नकल क्लस्टर" सूचकांक में मान उन 5 स्तंभों के लिए तेजी से खोज पथ के रूप में काम कर सकते हैं। यदि कोई गैर-अनुक्रमित स्तंभ या दो हैं जो नियमित रूप से भी चुने गए हैं, तो उन्हें सूचकांक में शामिल किया जा सकता है INCLUDE (Doctor_Name, Diagnosis_Synopsis)

हालाँकि मुझे सरल क्लस्टर इंडेक्स और प्राइमरी कीज़ उपयोगी लगती हैं, यह सोचने के लिए कुछ अच्छे कारण हैं कि उन्हें तालिका में या डेटाबेस में उपयोग करना है या नहीं।

क्या आपको क्लस्टर्ड इंडेक्स की आवश्यकता है?

  • यदि आप अनुक्रमणिका (विशिष्ट अनुक्रमणिका और गैर-अनन्य अनुक्रमणिका) बनाते हैं और प्राथमिक कुंजी को बिना Clustered अनुक्रमणिका के ओवरहेड को परिभाषित करते हैं, तो आप पा सकते हैं कि संकरी अनुक्रमणिकाएँ आपको प्रदान करती हैं कि आपको अपने प्रश्नों की आवश्यकता क्या है।

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

  • क्लस्टर्ड इंडेक्स के बिना आपके डेटा को पंक्ति पहचानकर्ता (RID) के साथ ढेर के रूप में संग्रहीत किया जाएगा जो कि एक अच्छा खोज तंत्र नहीं है। लेकिन, जैसा कि पहले उल्लेख किया गया है, आप अपने प्रश्नों को संभालने के लिए अद्वितीय और गैर-अद्वितीय अनुक्रमित बना सकते हैं।

जो अब आपको हीप्स पर विचार करने के लिए ले जाता है:

हीप्स एंड इंडेक्स: https://msdn.microsoft.com/en-us/library/hh213609.aspx

  • जब एक तालिका को एक ढेर के रूप में संग्रहीत किया जाता है, तो व्यक्तिगत पंक्तियों की पहचान एक पंक्ति पहचानकर्ता (आरआईडी) के संदर्भ में की जाती है जिसमें फ़ाइल नंबर, डेटा पृष्ठ संख्या और पृष्ठ पर स्लॉट शामिल होता है। पंक्ति आईडी एक छोटी और कुशल संरचना है। (लेकिन यह एक सूचकांक नहीं है ।)
  • कभी-कभी डेटा आर्किटेक्ट्स ढेर का उपयोग करते हैं जब डेटा को हमेशा गैर-अनुक्रमित अनुक्रमित के माध्यम से एक्सेस किया जाता है और आरआईडी एक क्लस्टर इंडेक्स कुंजी से छोटा होता है

लेकिन अगर आपके पास किसी बड़े डेटा सेट में कुछ 'हॉट स्पॉट' हैं, तो आप दूसरे प्रकार के सूचकांक में भी देख सकते हैं:

फ़िल्टर्ड इंडेक्स: https://msdn.microsoft.com/en-us/library/cc280372.aspx

  • एक अच्छी तरह से डिज़ाइन किया गया फ़िल्टर्ड इंडेक्स क्वेरी के प्रदर्शन और निष्पादन योजना की गुणवत्ता में सुधार करता है क्योंकि यह एक पूर्ण-टेबल नॉनस्ट्रेस्ड इंडेक्स से छोटा होता है और इसमें फ़िल्टर आँकड़े होते हैं। फ़िल्टर किए गए आँकड़े पूर्ण-तालिका आँकड़ों की तुलना में अधिक सटीक हैं क्योंकि वे फ़िल्टर्ड अनुक्रमणिका में केवल पंक्तियों को कवर करते हैं

  • फ़िल्टर्ड इंडेक्स में कई प्रतिबंध होते हैं जो फ़िल्टर्ड इंडेक्स के लिंक में उल्लिखित होते हैं।

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

http://use-the-index-luke.com/blog/2014-01/unreasonable-defaults-primary-key-clustering-key

लेकिन यह सब आखिरकार आपके आवेदन को समझने और कोड, टेबल, इंडेक्स, और आगे की डिजाइन को समझने के लिए वापस आता है।


इसके लायक होने के लिए, अपने दैनिक कार्य में अगर मुझे एक टेबल मिलती है जो एक ढेर है तो मैं समझता हूं कि यह सबसे अधिक त्रुटि है और डेवलपर्स के साथ यह देखने के लिए जांचें कि क्या यह जानबूझकर एक ढेर बना दिया गया था।
RLF

-2

विचार करने के लिए कुछ बिंदु।

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

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

मुझे लगता है कि आप एक क्लस्टर इंडेक्स से सबसे अधिक लाभान्वित होंगे जो एक प्रमुख रेंज स्कैन के लिए पूछ रहे सवालों को कवर करता है और अन्य कॉलमों को संदर्भित करता है।


वास्तव में एक समस्या बनने के लिए कितना उच्च दर होना चाहिए?
ypercube y

@ypercube क्या मैं कह सकता हूं "यह निर्भर करता है"? क्योंकि यह करता है। टेबल पर ट्रिगर्स की अनुपस्थिति में, मैं प्रति सेकंड 1K आवेषण कुल मिलाकर एक दर्जन धागे के साथ कुछ विवाद का सामना करना शुरू करूंगा।
४१

बिंदु में मामला: blogs.msdn.com/b/sqlserverfaq/archive/2010/05/05/27/…
mustaccio

मैं असहमत नहीं हूं, लेकिन मैं पूछ रहा था कि एक गर्म स्थान के साथ कितनी दूर जा सकते हैं। मुझे याद है कि एक तालिका में प्रति सेकंड 30K पंक्तियों को CI के रूप में सम्मिलित करने के बारे में एक लेख देखकर (यदि मेमोरी मुझे अच्छी तरह से परोसती है), लेकिन मुझे ब्लॉग पोस्ट नहीं मिल रही है।
ypercube y

यह चर्चा विशिष्ट हार्डवेयर पर एक ठोस स्कीमा के खिलाफ चल रहे एक ठोस कार्यभार के अभाव में व्यर्थ है। मुझे उम्मीद है कि हम सभी सहमत हो सकते हैं कि एक नीरस रूप से बढ़ते अनुक्रम पर एक सूचकांक "हॉट स्पॉट" पैदा करेगा; क्या यह एक अस्वीकार्य अड़चन पैदा करेगा और क्या किसी को इसकी परवाह करनी चाहिए या नहीं यह परिस्थितियों पर निर्भर करता है।
मस्तकियो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.