एक ही कॉलम पर एक अद्वितीय और सामान्य अनुक्रमणिका कितनी गलत है?

Question

मेरे पास निम्न तालिका संरचना

CREATE TABLE `table` (
    `id` int(11) NOT NULL auto_increment, 
    `date_expired` datetime NOT NULL, 
    `user_id` int(11) NOT NULL, 
    `foreign_id` int(11) NOT NULL, 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `date_expired` (`date_expired`,`user_id`,`foreign_id`), 
    KEY `user_id` (`user_id`) 
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

है जैसा कि आप देखेंगे, मेरे पास user_id पर डुप्लिकेट अनुक्रमणिका हैं: date_expired & user_id। मैं निश्चित रूप से अद्वितीय सूचकांक चाहता हूं क्योंकि मैं यह सुनिश्चित करना चाहता हूं कि डेटा अद्वितीय है।

डुप्लिकेट इंडेक्स का कारण है क्योंकि user_id अनुक्रमणिका के बिना, मेरी मुख्य खोज क्वेरी में 4 सेकंड लगते हैं। अतिरिक्त सूचकांक के साथ 1 सेकंड लगता है। क्वेरी user_id पर तालिका में शामिल हो रही है और date_expired जांच रही है।

तालिका में केवल 275 रिकॉर्ड हैं।

• एक ही क्षेत्र में एक अद्वितीय और सामान्य अनुक्रमणिका कितनी खराब है?
• तालिका पूरी तरह से आईडी के दौरान डेटा की तुलना में बड़ी अनुक्रमणिका होने में कितना बुरा है?

Answer 1

मेरा मानना ​​है कि अगर आप के रूप में (user_id, date_expired, foreign_id) अपने अद्वितीय सूचकांक बनाया है, तो आप सिर्फ अद्वितीय सूचकांक के साथ user_id पर एक सामान्य सूचकांक होने का एक ही लाभ मिलेगा। MySQL किसी भी इंडेक्स के पहले कॉलम का उपयोग user_id पर इंडेक्स के रूप में उसी तरह से जुड़ने के लिए पंक्तियों की संख्या को कम करने के लिए कर सकता है।

अधिक जानकारी के लिए MySQL's index documentation देखें।

क्या आप अंतरिक्ष बचाने के लिए अपनी स्कीमा में कहीं और id auto_increment कॉलम का जिक्र कर रहे हैं? चूंकि आपकी अनूठी अनुक्रमणिका आपकी तालिका के सभी अन्य कॉलम को कवर करती है, इसलिए यह संक्षेप में प्राथमिक कुंजी है और यदि आप नहीं हैं तो इसे छोड़ दिया जा सकता है।

आप जांच सकते हैं कि आपकी क्वेरी किस कुंजी को एक्सप्लाइन के साथ उपसर्ग करके उपयोग कर रही है।

Answer 2

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

प्रश्न जो मैं आपकी स्थिति में पूछूंगा वह है: ऐसी छोटी तालिका का अनुक्रमण कैसे मेरे क्वेरी रनटाइम को गंभीर रूप से प्रभावित करता है? शायद आप कुछ गलत कर रहे हैं (मुझे लगता है कि इस तालिका में संभवतः अनावश्यक पूछताछ के बारे में बहुत कुछ है), क्योंकि इस समय के पास किसी भी व्यक्ति को इस छोटी संख्या में प्रविष्टियों के साथ कहीं भी नहीं होना चाहिए)।

Answer 3

मुझे समझ में नहीं आता कि डुप्लिकेट इंडेक्स द्वारा आपका क्या मतलब है। आप तालिका में तीन अनुक्रमित है:

1. प्राथमिक कुंजी 'आईडी' (जो अद्वितीय तात्पर्य है)
2. की 'date_expired', 'user_id' संयोजन के लिए एक और अद्वितीय एक के लिए एक, और 'foreign_id'
3. और 'user_id' पर एक तिहाई एक ही

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

क्या बुरा हो सकता है, उदाहरण के लिए, एक अद्वितीय ('user_id') और बाद में एक प्रमुख ('user_id') (मैं भी यकीन है कि अगर MySQL कि अनुमति देगा नहीं कर रहा हूँ), क्योंकि एक सूचकांक होते हैं है अन्य और हासिल करने के लिए कुछ भी नहीं है।