MySQL में अनुक्रमणिका को समझना:भाग दो

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

MySQL में इंडेक्स और स्टोरेज इंजन

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

• MySQL दस्तावेज़ के अनुसार, इंडेक्स की अधिकतम संख्या, अधिकतम कुंजी लंबाई और अधिकतम इंडेक्स लंबाई है प्रति भंडारण इंजन परिभाषित। जैसा कि हमने पिछले ब्लॉग पोस्ट में पहले ही उल्लेख किया है, प्रति MyISAM और InnoDB तालिकाओं में अनुक्रमित की अधिकतम संख्या 64 है, दोनों भंडारण इंजनों में प्रति अनुक्रमणिका स्तंभों की अधिकतम संख्या 16 है, InnoDB के लिए अधिकतम कुंजी लंबाई 3500 बाइट्स है और अधिकतम MyISAM की कुंजी लंबाई 1000 बाइट्स है।

• आप प्राथमिक कुंजी बनाने के लिए CREATE INDEX का उपयोग नहीं कर सकते - इसके बजाय ALTER TABLE का उपयोग करें।

• BLOB और TEXT कॉलम को केवल InnoDB, MyISAM और BLACKHOLE स्टोरेज इंजन चलाने वाली टेबल के लिए इंडेक्स किया जा सकता है।

• यदि आप केवल कॉलम के उपसर्ग को अनुक्रमित करते हैं, तो ध्यान रखें कि उपसर्ग समर्थन और उनकी लंबाई भी भंडारण इंजन पर निर्भर है। InnoDB तालिकाओं के लिए एक उपसर्ग 767 बाइट्स तक लंबा हो सकता है जो REDUNDANT या COMPACT पंक्ति प्रारूप का उपयोग करते हैं, लेकिन DYNAMIC या COMPRESSED पंक्ति प्रारूपों के लिए उपसर्ग लंबाई सीमा 3072 बाइट्स तक बढ़ा दी जाती है। MyISAM तालिकाओं के लिए, उपसर्ग लंबाई सीमा 1000 बाइट्स है। NDB स्टोरेज इंजन उपसर्गों का बिल्कुल भी समर्थन नहीं करता है।

• यदि एक सख्त SQL मोड सक्षम है और अनुक्रमणिका उपसर्ग अधिकतम कॉलम डेटा प्रकार आकार से अधिक है, तो INDEX थ्रो बनाएं एक त्रुटि। यदि सख्त SQL मोड सक्षम नहीं है, तो CREATE INDEX एक चेतावनी उत्पन्न करता है। यदि कोई UNIQUE INDEX बनाया जाता है, तो एक त्रुटि उत्पन्न होती है।

• सामान्य तौर पर, MySQL आपको किसी दी गई टेबल पर केवल 16 इंडेक्स बनाने की अनुमति देता है।

• यदि आप प्राथमिक कुंजी अनुक्रमणिका का उपयोग कर रहे हैं, तो आपके पास प्रति तालिका केवल एक प्राथमिक कुंजी हो सकती है। FULLTEXT, UNIQUE INDEX और INDEX में यह सीमा नहीं है।

•  यदि आप FULLTEXT अनुक्रमणिका का उपयोग कर रहे हैं, तो ध्यान रखें कि उनका उपयोग केवल InnoDB या MyISAM संग्रहण इंजन के लिए किया जा सकता है और CHAR, VARCHAR या TEXT कॉलम के लिए। यह भी ध्यान रखें कि MySQL केवल FULLTEXT इंडेक्स का उपयोग करता है जब MATCH() AGAINST() क्लॉज का उपयोग किया जाता है और यदि आप चाहें तो एक ही कॉलम पर वास्तव में एक इंडेक्स और एक फुलटेक्स्ट इंडेक्स हो सकता है और यह कि FULLTEXT इंडेक्स उनके पास हैं उपयोग में आने वाले स्टोरेज इंजन के लिए प्रत्येक विशिष्ट स्टॉपवर्ड का अपना सेट।

• बी-ट्री इंडेक्स उपयोगी हो सकते हैं यदि आप वाइल्डकार्ड से शुरू होने वाली LIKE क्वेरी का उपयोग करते हैं, लेकिन केवल कुछ में परिदृश्य।

यदि आप यह समझने की कोशिश कर रहे हैं कि MySQL में अनुक्रमणिका कैसे काम करती है, तो इन सूचकांक सीमाओं को जानना उपयोगी साबित होना चाहिए। हालांकि यह समझना और भी महत्वपूर्ण है कि आपको यह सत्यापित करना होगा कि आपकी अनुक्रमणिका वास्तव में MySQL द्वारा उपयोग की जाती है। हमने इन श्रृंखलाओं के पहले भाग ("उपयोग करने के लिए सर्वश्रेष्ठ इंडेक्स कैसे चुनें?") में इस पर संक्षेप में बात की है, लेकिन हमने आपको यह नहीं बताया है कि कैसे सत्यापित करें कि आपकी अनुक्रमणिका वास्तव में MySQL द्वारा उपयोग की जाती है। ऐसा करने के लिए, EXPLAIN का उपयोग करके उनके उपयोग को सत्यापित करें - जब EXPLAIN का उपयोग एक व्याख्यात्मक कथन के साथ किया जाता है, तो MySQL कथन के निष्पादन योजना के बारे में अनुकूलक से जानकारी प्रदर्शित करता है।

प्राथमिक प्रमुख विचार

MySQL में PRIMARY KEY इंडेक्स से संबंधित कुछ बुनियादी बातों में यह तथ्य शामिल है कि वे मुख्य रूप से एक टेबल में रिकॉर्ड की विशिष्ट पहचान के लिए उपयोग किए जाते हैं और अक्सर AUTO_INCREMENTing मानों के साथ उपयोग किए जाते हैं, जिसका अर्थ है कि वे बहुत उपयोगी हो सकते हैं यदि आप आईडी फ़ील्ड बना रहे हैं, कहें। प्राथमिक कुंजी फ़ील्ड में अद्वितीय मान होने चाहिए और उनमें NULL मान नहीं हो सकते।

कॉलम उपसर्ग का मिलान करना

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

ALTER TABLE demo_table ADD INDEX index_name(column_name(length));

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

MySQL में FULLTEXT अनुक्रमणिका

MySQL में FULLTEXT इंडेक्स पूरी तरह से एक अलग जानवर हैं। उनके पास अपने लिए अद्वितीय कई सीमाएँ हैं (उदाहरण के लिए, InnoDB में स्टॉपवर्ड सूची है जिसमें 36 शब्द शामिल हैं जबकि MyISAM स्टॉपवर्ड सूची में 143 शब्द शामिल हैं), उनके पास अद्वितीय खोज मोड भी हैं। उनमें से कुछ में एक प्राकृतिक भाषा मोड शामिल है (ऐसे खोज मोड को सक्रिय करने के लिए, बिना किसी संशोधक के पूर्ण टेक्स्ट खोज क्वेरी चलाएं), आप अपनी खोज का विस्तार भी कर सकते हैं (ऐसा करने के लिए, क्वेरी विस्तार के साथ संशोधक का उपयोग करें - ऐसा खोज मोड निष्पादित करता है दो बार खोजें, लेकिन जब खोज दूसरी बार चलती है तो इसमें पहली खोज से कुछ सबसे प्रासंगिक रिकॉर्ड शामिल होते हैं - अक्सर उपयोग किया जाता है जब उपयोगकर्ता ने कुछ का ज्ञान निहित किया है), बूलियन ऑपरेटरों के साथ खोज करने के लिए इन बूलियन मोड संशोधक का उपयोग करें। FULLTEXT अनुक्रमणिका का उपयोग केवल तभी किया जाएगा जब खोज क्वेरी में InnoDB के लिए न्यूनतम तीन वर्ण और MyISAM के लिए न्यूनतम चार वर्ण हों।

वाइल्डकार्ड के साथ बी-ट्री इंडेक्स का उपयोग करना

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

SELECT * FROM … WHERE demo_column LIKE ‘search%’;

इस तरह की एक क्वेरी किसी भी चीज़ से शुरू होने वाले परिणामों की खोज करेगी, जिसमें "खोज" शब्द होगा और उसके बाद कुछ भी होगा:

SELECT * FROM … WHERE demo_column LIKE ‘%search%’;

लेकिन यहाँ एक पकड़ है - उपरोक्त क्वेरी किसी अनुक्रमणिका का उपयोग नहीं करेगी। क्यों? क्योंकि इसकी शुरुआत में एक वाइल्डकार्ड होता है और MySQL यह पता नहीं लगा सकता है कि कॉलम को किससे शुरू करना है। इसलिए हमने कहा कि वाइल्डकार्ड इंडेक्स का अपना स्थान होता है, लेकिन केवल विशिष्ट परिदृश्यों में - यानी ऐसे परिदृश्य जहां आपके पास अपनी खोज क्वेरी की शुरुआत में वाइल्डकार्ड नहीं होता है।

क्वेरी के प्रदर्शन की निगरानी के लिए ClusterControl का उपयोग करना

EXPLAIN का उपयोग करने के अलावा, आप अपने प्रश्नों के प्रदर्शन की निगरानी के लिए ClusterControl का भी उपयोग कर सकते हैं:ClusterControl उन्नत निगरानी और रिपोर्टिंग सुविधाओं का एक सेट प्रदान करता है जो आपको अपने डेटाबेस इंस्टेंस और क्वेरी के प्रदर्शन का ट्रैक रखने देता है। . उदाहरण के लिए, क्लस्टर पर क्लिक करें और आपको "क्वेरी मॉनिटर" टैब दिखाई देगा। उस पर क्लिक करें और ClusterControl आपको अपने डेटाबेस इंस्टेंस में अपने प्रश्नों की स्थिति देखने देगा:

ClusterControl के इस भाग से आप शीर्ष धीमी और लंबी सूची देख सकते हैं- चल रहे प्रश्न आपको उनके माध्यम से फ़िल्टर करने की अनुमति भी देते हैं। उदाहरण के लिए यदि आप जानते हैं कि कुछ समय पहले आपने @@log_bin वाली एक क्वेरी चलाई थी, तो आप बस शब्द खोज सकते हैं और ClusterControl परिणामों की एक सूची लौटाएगा:

जैसा कि आपने शायद देखा है, आप अपने द्वारा उपयोग किए जाने वाले होस्ट द्वारा क्वेरी को फ़िल्टर भी कर सकते हैं या बार-बार, आप पंक्तियों का एक सेट देखने का चुनाव भी कर सकते हैं, उदाहरण के लिए, 20, 100 या 200। ClusterControl आपको यह भी बताएगा कि क्वेरी को आखिरी बार कब देखा गया था, इसका कुल निष्पादन समय क्या था, यह कितनी पंक्तियों में लौटा था, इसने कितनी पंक्तियों की जाँच की वगैरह। यदि आप यह देखना चाहते हैं कि MySQL, MariaDB, MongoDB, PostgreSQL या TimescaleDB इंस्टेंस द्वारा वास्तव में आपकी अनुक्रमणिका का उपयोग कैसे किया जाता है, तो ClusterControl सहायक साबित हो सकता है।

सारांश

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