असल में, आपकी प्राथमिक कुंजी ऐसी श्रेणी क्वेरी के संदर्भ में बहुत कम समझ में आती है। यह केवल <from_ip, to_ip> . के लिए अद्वितीय युग्मों को इंगित करता है tuple - इस प्रकार, MySQL ऐसी श्रेणी तुलनाओं के साथ उस अनुक्रमणिका का उपयोग करने में सक्षम नहीं होगा।
जब तक आप कुछ क्वेरी नहीं चला रहे हैं जिसमें आपकी प्राथमिक कुंजी के दोनों भाग शामिल हैं, इसका कोई प्रभाव नहीं होगा (ठीक है, वास्तव में, MySQL भी इसका उपयोग करेगा - जब चयन की स्थिति यौगिक अनुक्रमणिका का बायां उपसमूह , लेकिन यह आपका मामला नहीं है)। उदाहरण के लिए, यह प्राथमिक कुंजी का उपयोग करेगा:
-- @x and @y are derived from somewhere else
SELECT * FROM inetnum WHERE [email protected] && [email protected]
आपके मामले में, यौगिक कुंजी प्राथमिक कुंजी हो सकती है, हां, लेकिन इसका केवल लाभ होगा - विशिष्टता प्रदान करने के लिए। तो, आप इसे वैसे ही छोड़ सकते हैं, या सरोगेट बना सकते हैं id प्राथमिक कुंजी (वर्तमान प्राथमिक कुंजी के स्थान पर UNIQUE बाधा)।
स्थिति में सुधार के संभावित समाधानों में से एक हो सकता है - from_ip . के लिए सिंगल-कॉलम कुंजियां बनाएं और to_ip . चूंकि वे पूर्णांक हैं, इसलिए उच्च कार्डिनैलिटी के लिए एक अच्छा मौका है, जो परिणाम अनुक्रमित होगा। हालांकि, MySQL केवल एक इंडेक्स का उपयोग कर सकता है, और इसलिए, आप रेंज कुशल तुलना का 'आधा' खो देंगे। आपको यह भी याद रखना चाहिए, कि यदि अधिक से अधिक (या कम-से) तुलना बहुत अधिक पंक्तियों को प्रभावित करेगी, तो MySQL होगा इंडेक्स का भी उपयोग न करें (क्योंकि, जाहिर है, इसमें कोई मतलब नहीं है क्योंकि चयन करने के लिए बहुत अधिक पंक्तियां हैं)।
और - हाँ, WHERE . में फ़ंक्शन का उपयोग करने से बचें खंड। मैं यह नहीं कह रहा हूं कि ऐसे मामले में MySQL हमेशा इंडेक्स उपयोग को खो देगा (लेकिन सबसे अधिक संभावना है, यह ज्यादातर मामलों में इसे खो देगा) - लेकिन ओवरहेड के बारे में सोचें जो फ़ंक्शन कॉल का कारण बन जाएगा। यहां तक कि अगर यह छोटा है - आप अपने आवेदन द्वारा गठित सही मान पास करके हमेशा इससे छुटकारा पा सकते हैं।
