शब्द काफी तार्किक हैं और आप उन्हें बहुत जल्दी सीख जाएंगे। :)
आम आदमी के शब्दों में, SEEK का तात्पर्य रिकॉर्ड के लिए सटीक स्थानों की तलाश करना है, जो कि SQL सर्वर तब करता है जब आप जिस कॉलम को खोज रहे हैं उसे अनुक्रमित किया जाता है, और आपका फ़िल्टर (WHERE स्थिति) पर्याप्त रूप से सटीक होता है।
स्कैन का मतलब पंक्तियों की एक बड़ी रेंज है जहां क्वेरी निष्पादन योजनाकार का अनुमान है कि प्रत्येक मान की व्यक्तिगत रूप से मांग करने के विपरीत एक पूरी श्रृंखला प्राप्त करना तेज़ है।
और हाँ, आपके पास एक ही फ़ील्ड पर कई अनुक्रमणिकाएँ हो सकती हैं, और कभी-कभी यह एक बहुत अच्छा विचार हो सकता है। इंडेक्स के साथ खेलें और क्या होता है यह निर्धारित करने के लिए क्वेरी निष्पादन योजनाकार का उपयोग करें (एसएसएमएस में शॉर्टकट:Ctrl + M)। आप एक ही क्वेरी के दो संस्करण भी चला सकते हैं और निष्पादन योजनाकार आपको आसानी से दिखाएगा कि प्रत्येक द्वारा कितना संसाधन और समय लिया जाता है, जिससे अनुकूलन काफी आसान हो जाता है।
लेकिन इन पर थोड़ा विस्तार करने के लिए, मान लें कि आपके पास ऐसा पता तालिका है, और इसमें 1 बिलियन से अधिक रिकॉर्ड हैं:
CREATE TABLE ADDRESS
(ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
, PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
, CITY VARCHAR(256)
, MARKED_FOR_CHECKUP BIT
, **+n^10 different other columns...**)
अब, यदि आप व्यक्ति 12345 के लिए सभी पते की जानकारी प्राप्त करना चाहते हैं, तो PERSON_ID पर अनुक्रमणिका एकदम सही है। चूंकि तालिका में एक ही पंक्ति पर अन्य डेटा का भार है, इसलिए अन्य सभी स्तंभों के साथ-साथ PERSON_ID को कवर करने के लिए एक गैर-संकुल सूचकांक बनाना अक्षम और स्थान लेने वाला होगा। इस मामले में, SQL सर्वर PERSON_ID में अनुक्रमणिका SEEK को निष्पादित करेगा, फिर ADDRESS_ID में संकुल अनुक्रमणिका पर एक कुंजी लुकअप करने के लिए इसका उपयोग करेगा, और वहां से उसी पंक्ति के अन्य सभी स्तंभों में सभी डेटा लौटाएगा।
हालाँकि, मान लें कि आप किसी शहर में सभी व्यक्तियों को खोजना चाहते हैं, लेकिन आपको अन्य पते की जानकारी की आवश्यकता नहीं है। इस बार, सबसे प्रभावी तरीका यह होगा कि CITY पर एक इंडेक्स बनाया जाए और PERSON_ID को भी कवर करने के लिए INCLUDE विकल्प का उपयोग किया जाए। इस तरह, एक एकल अनुक्रमणिका खोज/स्कैन एक ही पंक्ति में PERSON_ID डेटा के लिए CLUSTERED अनुक्रमणिका की जाँच करने की आवश्यकता के बिना आपको आवश्यक सभी जानकारी लौटा देगी।
अब, मान लें कि उन दोनों प्रश्नों की आवश्यकता है, लेकिन 1 बिलियन रिकॉर्ड के कारण अभी भी भारी हैं। लेकिन एक विशेष प्रश्न है जिसे वास्तव में वास्तव में तेज़ होना चाहिए। वह प्रश्न उन सभी व्यक्तियों को चाहता है जो उन पतों पर हैं जो MARKED_FOR_CHECKUP रहे हैं, और जिन्हें न्यूयॉर्क में रहना चाहिए (जो भी चेकअप का मतलब है उसे अनदेखा करें, इससे कोई फर्क नहीं पड़ता)। अब आप MARKED_FOR_CHECKUP और CITY पर एक तीसरा, फ़िल्टर्ड इंडेक्स बनाना चाहते हैं, जिसमें INCLUDE PERSON_ID को कवर करता है, और एक फ़िल्टर के साथ CITY ='न्यूयॉर्क' और MARKED_FOR_CHECKUP =1 कहता है। यह इंडेक्स बहुत तेज़ होगा, क्योंकि यह केवल प्रश्नों को कवर करता है। जो उन सटीक शर्तों को पूरा करते हैं, और इसलिए अन्य इंडेक्स की तुलना में डेटा का एक अंश है।
(यहां अस्वीकरण, ध्यान रखें कि क्वेरी निष्पादन योजनाकार बेवकूफ नहीं है, यह सही परिणाम उत्पन्न करने के लिए एक साथ कई गैर-अनुक्रमित अनुक्रमणिका का उपयोग कर सकता है, इसलिए ऊपर दिए गए उदाहरण सर्वोत्तम उपलब्ध नहीं हो सकते हैं क्योंकि यह कल्पना करना बहुत कठिन है कि आपको कब आवश्यकता होगी एक ही कॉलम को कवर करने वाले 3 अलग-अलग इंडेक्स, लेकिन मुझे यकीन है कि आपको इसका अंदाजा हो गया है।)
इंडेक्स के प्रकार, उनके कॉलम, कॉलम, सॉर्टिंग ऑर्डर, फिल्टर आदि पूरी तरह से स्थिति पर निर्भर करते हैं। आपको कई अलग-अलग प्रकार के प्रश्नों को पूरा करने के लिए कवरिंग इंडेक्स बनाने की आवश्यकता होगी, साथ ही विशेष रूप से एकवचन, महत्वपूर्ण प्रश्नों के लिए बनाए गए अनुकूलित इंडेक्स। प्रत्येक इंडेक्स एचडीडी पर जगह लेता है इसलिए बेकार इंडेक्स बनाना बेकार है और जब भी डेटा मॉडल बदलता है तो अतिरिक्त रखरखाव की आवश्यकता होती है, और डीफ़्रैग्मेन्टेशन और आंकड़े अपडेट संचालन में समय बर्बाद होता है ... या तो।
प्रयोग करें, सीखें और काम करें जो आपकी आवश्यकताओं के लिए सबसे अच्छा काम करता है।
