UNIQUEIDENTIFIER (निष्पादन योजना के अनुसार) से अधिक कुशल क्यों नहीं है?

Question

मेरे पास एक अभिभावक तालिका और बाल तालिका है जहां कॉलम जो उनसे जुड़ते हैं वे अद्वितीय प्रकार के होते हैं।

बच्चे की तालिका में कॉलम पर एक क्लस्टर्ड इंडेक्स है जो इसे मूल तालिका में जोड़ता है (इसका पीके, जिसे क्लस्टर भी किया जाता है)।

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

जब मैं अभिभावक तालिका से ज्ञात 20 रिकॉर्ड्स के लिए पूछता हूं, तो बाल तालिकाओं से सभी संबंधित रिकॉर्ड्स खींचते हुए, मुझे बैच के लिए 50/50 लागत दोनों में समान क्वेरी लागत मिलती है।

यदि यह सत्य है, तो इस तरह की सभी तालिकाओं को बदलने के लिए मेरी विशाल परियोजना गतिशील आवेषण के अलावा व्यर्थ दिखाई देती है। क्या कोई स्थिति पर कोई प्रकाश प्रदान कर सकता है?

---

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

सवाल जो के बारे में अधिक कुशल है नहीं है, लेकिन क्यों क्वेरी कार्य योजना लागू करके एक ही कीमत होने के रूप में दोनों प्रश्नों दिखा रहा है?

Answer 1

क्लस्टर्ड इंडेक्स में एक कुंजी की तलाश मूल रूप से 4 बाइट कुंजी, 16 बाइट कुंजी या 160 बाइट कुंजी पर समान होती है। भविष्यवाणी के साथ स्लॉट की तुलना करने की लागत केवल क्वेरी की कुल लागत (निष्पादन तैयारी, निष्पादन संदर्भ तैयार करने, पंक्तियों को खोलने, पृष्ठों को ढूंढने आदि), में शोर है, भले ही कोई आईओ शामिल नहीं है।

हालांकि कोई भी तर्क नहीं देगा कि GUID और INT समान पैर पर हैं, केवल 20 खोजों की तुलना में मतभेद प्रकट नहीं होंगे। एक बात यह है कि आप माप सकते हैं तुरंत स्थान है: प्रति पंक्ति 12 बाइट्स की बचत और क्लस्टरर्ड इंडेक्स पर प्रति गैर-पत्ती पृष्ठ, साथ ही गैर-क्लस्टर इंडेक्स पर प्रत्येक पत्ते पृष्ठ पर 12 बाइट लाखों पंक्तियों को जोड़ देंगे और टेबल और इंडेक्स के दसियों। कम जगह का अर्थ है IO, बेहतर मेमोरी कैश प्रदर्शन, समग्र रूप से बेहतर भलाई, और मापा जा सकता है, लेकिन आपको वास्तविक भार मापने की आवश्यकता है, न कि 20 पंक्तियों की तलाश करें।

प्रयोगशाला स्थितियों के तहत आप एक आईएनटी या एक GUID की तलाश के बीच कच्ची गति में अंतर को मापने में सक्षम होंगे, लेकिन यह आपका ध्यान नहीं होना चाहिए। आईएनटी बनाम GUID का तर्क किसी खोज में 5% प्रदर्शन लाभ की तरह कुछ नहीं होता है, अंतरिक्ष बचत द्वारा संचालित होता है और गुंडे यादृच्छिकता से विखंडन की ओर जाता है, दोनों मेट्रिक्स को मापने में बहुत आसान होता है जो स्वयं के लिए एक ठोस मामला बनाते हैं आधार, प्रदर्शन प्रदर्शन तर्क लाने की जरूरत नहीं है।

Answer 2

अधिक अधिक कुशल।

Int बहुत छोटा है। इसका मतलब है कि आपको बहुत छोटे सूचकांक मिलते हैं, जिसका अर्थ है कि आपको सूचकांक पहुंच के लिए बेहतर स्मृति उपयोग और लोड समय मिलता है। यह बहुत निर्भर करता है, हालांकि, आपके टेबल कितने बड़े हैं और आप उनके साथ क्या करते हैं।

Answer 3

क्लसर्ड इंडेक्स के लिए GUID का उपयोग करके, क्लस्टर इंडेक्स के लिए GUID का उपयोग करके, आईओ के संदर्भ में प्रश्नों के प्रदर्शन को प्रभावित करने वाले अधिकांश मामलों में उनके लिए जबरदस्त विखंडन हो रहा है। ऐसा तब होता है जब आप क्रमिक रूप से जेनरेट किए गए ग्रिड का उपयोग नहीं करते हैं, जो मुझे लगता है कि ज्यादातर एप्लिकेशन डेटाबेस के बाहर guid उत्पन्न करते समय होता है। अनुक्रमिक GUID बनाने के लिए ('बड़ा' पहले से डेटाबेस में उत्पन्न की तुलना में) आप समारोह एक बैच में दो योजनाओं की लागत का newsequentialid()

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