क्लस्टर इंडेक्स चयन - पीके या एफके?

11

मेरे पास SQL Server 2014 टेबल है जो निम्न की तरह दिखता है:

OrderId     int           not null IDENTITY --this is the primary key column
OrderDate   datetime2     not null
CustomerId  int           not null
Description nvarchar(255) null

मेरी टीम के कुछ लोगों ने सुझाव दिया है कि क्लस्टर इंडेक्स चालू होना चाहिए OrderId, लेकिन मुझे लगता है कि निम्नलिखित कारणों से CustomerId+ OrderIdएक बेहतर विकल्प होगा:

लगभग सभी प्रश्न दिख रहे होंगे WHERE CustomerId = @param, नहींOrderId
CustomerIdCustomerतालिका के लिए एक विदेशी कुंजी है , इसलिए क्लस्टरिंग इंडेक्स के साथ CustomerIdजुड़ने की गति तेज होनी चाहिए
जबकि CustomerIdअद्वितीय नहीं है, अतिरिक्त होने OrderIdसूचकांक में निर्दिष्ट स्तंभ विशिष्टता यह सुनिश्चित करेंगे (हम उपयोग कर सकते हैं UNIQUEजब उन 2 कॉलम पर संकुल अनुक्रमणिका बनाने कीवर्ड, विशिष्टता नहीं होने की भूमि के ऊपर से बचने के लिए)
एक बार डेटा डालने के बाद, CustomerIdऔर OrderIdकभी नहीं बदलता है, इसलिए ये पंक्तियाँ प्रारंभिक लेखन के बाद चारों ओर नहीं घूमेंगी।
डेटा का उपयोग एक ORM के माध्यम से होता है जो डिफ़ॉल्ट रूप से सभी स्तंभों का अनुरोध करता है, इसलिए जब कोई क्वेरी CustomerIdअंदर आती है, तो क्लस्टर इंडेक्स बिना किसी अतिरिक्त कार्य के सभी कॉलम प्रदान करने में सक्षम होगा।

क्या ऊपर दिए गए सर्वश्रेष्ठ विकल्प की तरह ध्वनि CustomerIdऔर OrderIdदृष्टिकोण ध्वनि है? या, यह OrderIdअपने आप बेहतर है, क्योंकि यह एक एकल स्तंभ है जो अपने आप में विशिष्टता की गारंटी दे रहा है?

वर्तमान में, तालिका में एक क्लस्टर अनुक्रमणिका OrderIdऔर एक गैर-अनुक्रमित अनुक्रमणिका है CustomerId, लेकिन यह कवर नहीं कर रहा है, इसलिए जब से हम ORM का उपयोग कर रहे हैं और सभी स्तंभों का अनुरोध किया गया है, उन्हें पुनः प्राप्त करना अतिरिक्त कार्य है। इसलिए इस पोस्ट के साथ, मैं बेहतर सीआई के साथ प्रदर्शन में सुधार करने पर विचार करने की कोशिश कर रहा हूं।

हमारे DB पर गतिविधि लगभग 85% पढ़ती है और 15% लिखता है।

sql-server clustered-index

— एंडी
स्रोत

5

_{सामुदायिक विकि उत्तर :}

मुझे लगता है कि पहले कॉलम के रूप में CustomerID के साथ एक संयुक्त संकुल सूचकांक कुंजी सबसे अच्छी होगी क्योंकि यह WHEREलगभग सभी प्रश्नों के खंड में है।

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

ऑर्डरड या ऑर्डरडेट आपके सबसे महत्वपूर्ण प्रश्नों के आधार पर दूसरे कॉलम के लिए सबसे अच्छा हो सकता है।

उदाहरण के लिए, यदि ग्राहक वेब साइट में लॉग इन करने के बाद हाल के आदेशों की कालानुक्रमिक सूची देखते हैं, तो ऑर्डरडेट को अनुकूलन करने के लिए अगला होना चाहिए ORDER BY OrderDate DESC।

यदि आप चुनते हैं OrderID पर एक गैर-संकुल अनुक्रमणिका के साथ, संकुल अनुक्रमणिका के रूप में CustomerID , आप अभी भी विभाजन और विखंडन मिल जाएगा, बस गैर संकुल अनुक्रमणिका में।

— रेव्स , 3 उपयोगकर्ता 72% user126897
स्रोत

3

यदि यह तालिका गहन रूप से लिखी गई है (जैसे कि इसके खिलाफ बयानों के INSERTबजाय कई और बयान हो रहे हैं SELECT), मैं विकी जवाब से असहमत होने जा रहा हूं ।

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

यदि आपको लगता है कि CustomerID एक समग्र क्लस्टर इंडेक्स का एक प्रमुख स्तंभ होना चाहिए, तो आप FILLFACTORइस तालिका के लिए सभी इंडेक्स पर समायोजित करके मध्य-पृष्ठ विभाजन के प्रभाव को कम कर सकते हैं । यह तालिका / सूचकांक के आकार को बढ़ाकर मध्य-पृष्ठ विभाजन की मात्रा को कम करेगा। यदि आप इस मार्ग पर जाना चाहते हैं, तो मेरा सुझाव है कि 80 के मान के साथ परीक्षण करें और यदि विश्लेषण से पता चलता है कि मध्य-पृष्ठ विभाजन अभी भी प्रदर्शन को मार रहे हैं।

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

हमारे DB पर गतिविधि लगभग 85% पढ़ती है और 15% लिखता है।

CustomerID+ OrderID(विभाजन के बिना वृद्धि की अनुमति देने के लिए एक भराव को निर्दिष्ट करना) शायद बेहतर होता है यदि यह आकलन सही हो। बस यह सुनिश्चित करें कि मूल्यांकन सटीक हो। परीक्षण परीक्षण परीक्षण।

— जॉन आइस्ब्रेनर
स्रोत

1

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

— डेविड ब्राउन - Microsoft