MySQL इंडेक्स कैसे काम करते हैं?

पहली बात जो आपको जाननी चाहिए वह यह है कि अनुक्रमणिका एक ऐसा तरीका है जिससे आप जो परिणाम खोज रहे हैं उसे प्राप्त करने के लिए पूर्ण तालिका को स्कैन करने से बच सकते हैं।

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

InnoDB और B+ट्री इंडेक्स

InnoDB के लिए, सबसे सामान्य इंडेक्स प्रकार B+ट्री आधारित इंडेक्स है, जो तत्वों को एक क्रमबद्ध क्रम में संग्रहीत करता है। साथ ही, आपको अनुक्रमित मान प्राप्त करने के लिए वास्तविक तालिका तक पहुंचने की आवश्यकता नहीं है, जिससे आपकी क्वेरी तेजी से वापस आती है।

इस इंडेक्स प्रकार के बारे में "समस्या" यह है कि आपको इंडेक्स का उपयोग करने के लिए सबसे बाएं मान के लिए पूछना होगा। इसलिए, यदि आपकी अनुक्रमणिका में दो स्तंभ हैं, जैसे last_name और first_name, तो आप इन फ़ील्ड को क्वेरी करने का क्रम बहुत मायने रखते हैं ।

तो, निम्न तालिका दी गई है:

CREATE TABLE person (
    last_name VARCHAR(50) NOT NULL,
    first_name VARCHAR(50) NOT NULL,
    INDEX (last_name, first_name)
);

यह क्वेरी इंडेक्स का लाभ उठाएगी:

SELECT last_name, first_name FROM person
WHERE last_name = "John" AND first_name LIKE "J%"

लेकिन निम्नलिखित नहीं होगा

SELECT last_name, first_name FROM person WHERE first_name = "Constantine"

क्योंकि आप first_name . को क्वेरी कर रहे हैं कॉलम पहले और यह इंडेक्स में सबसे बाएं कॉलम नहीं है।

यह आखिरी उदाहरण और भी बुरा है:

SELECT last_name, first_name FROM person WHERE first_name LIKE "%Constantine"

क्योंकि अब, आप अनुक्रमणिका में सबसे दाहिने क्षेत्र के सबसे दाहिने हिस्से की तुलना कर रहे हैं।

हैश इंडेक्स

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

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

यदि आपके पास एक बड़ा VARCHAR है फ़ील्ड, आप बी-ट्री का उपयोग करते समय हैश इंडेक्स के उपयोग का "अनुकरण" कर सकते हैं, एक और कॉलम बनाकर और उस पर बड़े मूल्य के हैश को सहेज सकते हैं। मान लें कि आप किसी फ़ील्ड में url संग्रहीत कर रहे हैं और मान काफी बड़े हैं। आप url_hash . नामक एक पूर्णांक फ़ील्ड भी बना सकते हैं और CRC32 . जैसे हैश फ़ंक्शन का उपयोग करें या किसी अन्य हैश फ़ंक्शन को सम्मिलित करते समय url को हैश करने के लिए। और फिर, जब आपको इस मान के लिए क्वेरी करने की आवश्यकता हो, तो आप ऐसा कुछ कर सकते हैं:

SELECT url FROM url_table WHERE url_hash=CRC32("http://gnu.org");

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

SELECT url FROM url_table 
WHERE url_hash=CRC32("http://gnu.org") AND url="http://gnu.org";

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

दुर्भाग्य से, इस तकनीक का उपयोग करते हुए, आपको अभी भी url . की तुलना करने के लिए तालिका को हिट करने की आवश्यकता है फ़ील्ड.

रैप अप

कुछ तथ्य जिन पर आप हर बार ऑप्टिमाइज़ेशन के बारे में बात करते समय विचार कर सकते हैं:

1. स्ट्रिंग तुलना की तुलना में पूर्णांक तुलना तेज़ है। इसे InnoDB . में हैश इंडेक्स के अनुकरण के उदाहरण के साथ चित्रित किया जा सकता है ।

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

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

मैं आपको "हाई परफॉर्मेंस माईएसक्यूएल" पुस्तक पढ़ने की अत्यधिक अनुशंसा करता हूं, उपरोक्त उत्तर निश्चित रूप से इंडेक्स के बारे में अपने अध्याय पर आधारित था।