समूह के साथ और कहां से चुनिंदा गिनती (*) को कैसे तेज करें?

बढ़ती हुई कठिनाई के क्रम में मैं यहाँ कई चीज़ें आज़माऊँगा:

(आसान) - सुनिश्चित करें कि आपके पास सही कवरिंग इंडेक्स है

CREATE INDEX ix_temp ON relations (relation_title, object_title);

यह आपके मौजूदा स्कीमा को अधिकतम करने के लिए चाहिए, क्योंकि (जब तक कि mySQL के अनुकूलक का आपका संस्करण वास्तव में गूंगा नहीं है!) यह आपकी क्वेरी को संतुष्ट करने के लिए आवश्यक I/Os की मात्रा को कम कर देगा (इसके विपरीत यदि अनुक्रमणिका विपरीत क्रम में है जहां संपूर्ण अनुक्रमणिका स्कैन किया जाना चाहिए) और यह क्वेरी को कवर करेगा ताकि आपको क्लस्टर्ड इंडेक्स को स्पर्श न करना पड़े।

(थोड़ा कठिन) - सुनिश्चित करें कि आपके वर्चर फ़ील्ड यथासंभव छोटे हैं

MySQL पर वर्चर इंडेक्स के साथ पूर्ण चुनौतियों में से एक यह है कि, किसी क्वेरी को संसाधित करते समय, फ़ील्ड का पूर्ण घोषित आकार रैम में खींच लिया जाएगा। तो यदि आपके पास वर्कर (256) है लेकिन केवल 4 वर्णों का उपयोग कर रहे हैं, तो भी आप क्वेरी संसाधित होने के दौरान 256-बाइट रैम उपयोग का भुगतान कर रहे हैं। आउच! इसलिए यदि आप अपनी वर्चर सीमा को आसानी से कम कर सकते हैं, तो इससे आपके प्रश्नों में तेजी आनी चाहिए।

(कठिन) - सामान्य करें

एकल स्ट्रिंग मान वाली आपकी 30% पंक्तियाँ किसी अन्य तालिका में सामान्यीकरण के लिए एक स्पष्ट रोना है, इसलिए आप लाखों बार स्ट्रिंग्स की नकल नहीं कर रहे हैं। तीन तालिकाओं में सामान्यीकृत करने और उनमें शामिल होने के लिए पूर्णांक आईडी का उपयोग करने पर विचार करें।

कुछ मामलों में, आप कवर के नीचे सामान्यीकृत कर सकते हैं और वर्तमान तालिका के नाम से मेल खाने वाले विचारों के साथ सामान्यीकरण छुपा सकते हैं ... .

(सबसे कठिन) - अपने स्ट्रिंग कॉलम को हैश करें और हैश को इंडेक्स करें

यदि सामान्यीकरण का अर्थ है बहुत अधिक कोड बदलना, लेकिन आप अपनी स्कीमा को थोड़ा बदल सकते हैं, तो आप अपने स्ट्रिंग कॉलम के लिए 128-बिट हैश बनाने पर विचार कर सकते हैं (MD5 फ़ंक्शन ) इस मामले में (सामान्यीकरण के विपरीत) आपको अपने सभी प्रश्नों को बदलने की जरूरत नहीं है, केवल INSERTs और कुछ SELECTs। वैसे भी, आप अपने स्ट्रिंग फ़ील्ड को हैश करना चाहते हैं, और फिर हैश पर एक इंडेक्स बनाना चाहते हैं, उदा।

CREATE INDEX ix_temp ON relations (relation_title_hash, object_title_hash);

ध्यान दें कि आपको यह सुनिश्चित करने के लिए चयन के साथ खेलना होगा कि आप हैश इंडेक्स के माध्यम से गणना कर रहे हैं और क्लस्टर इंडेक्स में नहीं खींच रहे हैं (क्वेरी को संतुष्ट करने के लिए ऑब्जेक्ट_टाइटल के वास्तविक टेक्स्ट मान को हल करने के लिए आवश्यक है)।

साथ ही, यदि संबंध_शीर्षक का वर्चर आकार छोटा है लेकिन ऑब्जेक्ट शीर्षक का आकार लंबा है, तो आप संभावित रूप से केवल ऑब्जेक्ट_टाइटल हैश कर सकते हैं और (relation_title, object_title_hash) पर इंडेक्स बना सकते हैं। ।

ध्यान दें कि यह समाधान केवल तभी मदद करता है जब इनमें से एक या दोनों फ़ील्ड हैश के आकार के सापेक्ष बहुत लंबे हों।

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