संक्षिप्त उत्तर हां है, प्राथमिक कुंजी का एक क्रम होता है, सभी अनुक्रमणिकाओं का एक क्रम होता है, और प्राथमिक कुंजी केवल एक अद्वितीय अनुक्रमणिका होती है।
जैसा कि आपने ठीक ही कहा है, आपको डेटा को उसी क्रम में लौटाए जाने पर भरोसा नहीं करना चाहिए जिस क्रम में डेटा संग्रहीत किया गया है, ऑप्टिमाइज़र इसे किसी भी क्रम में वापस करने के लिए स्वतंत्र है, और यह क्वेरी योजना पर निर्भर होगा। हालांकि मैं यह समझाने की कोशिश करूंगा कि आपकी क्वेरी ने 12 साल तक काम क्यों किया।
आपका क्लस्टर्ड इंडेक्स सिर्फ आपका टेबल डेटा है, और आपकी क्लस्टरिंग कुंजी उस क्रम को परिभाषित करती है जिसमें इसे संग्रहीत किया जाता है। डेटा को लीफ पर संग्रहीत किया जाता है, और क्लस्टरिंग कुंजी रूट (और इंटरमीडिएट नोट्स) को जल्दी से प्राप्त करने के लिए पॉइंटर्स के रूप में कार्य करने में मदद करती है। डेटा पुनर्प्राप्त करने के लिए दायां पत्ता। एक गैर-संकुल सूचकांक एक बहुत ही समान संरचना है, लेकिन निम्नतम स्तर में क्लस्टर सूचकांक के पत्ते पर सही स्थिति के लिए एक सूचक होता है।
MySQL में प्राथमिक कुंजी और क्लस्टर इंडेक्स समानार्थी हैं, इसलिए प्राथमिक कुंजी का आदेश दिया जाता है, हालांकि वे मूल रूप से दो अलग-अलग चीजें हैं। अन्य डीबीएमएस में आप प्राथमिक कुंजी और क्लस्टर इंडेक्स दोनों को परिभाषित कर सकते हैं, जब आप ऐसा करते हैं तो आपकी प्राथमिक कुंजी क्लस्टर इंडेक्स पर पॉइंटर के साथ एक अद्वितीय गैर-क्लस्टर इंडेक्स बन जाती है।
इसके सबसे सरल शब्दों में आप एक आईडी कॉलम वाली तालिका की कल्पना कर सकते हैं जो प्राथमिक कुंजी है, और दूसरा कॉलम (ए), आपके क्लस्टर इंडेक्स के लिए आपकी बी-ट्री संरचना कुछ इस तरह होगी:
Root Node
+---+
| 1 |
+---+
Intermediate Nodes
+---+ +---+ +---+
| 1 | | 4 | | 7 |
+---+ +---+ +---+
Leaf
+-----------+ +-----------+ +-----------+
ID -> | 1 | 2 | 3 | | 4 | 5 | 6 | | 7 | 8 | 9 |
A -> | A | B | C | | D | E | F | | G | H | I |
+-----------+ +-----------+ +-----------+
वास्तव में लीफ पेज बहुत बड़े होंगे, लेकिन यह सिर्फ एक डेमो है। पेड़ को पार करने में आसानी के लिए प्रत्येक पृष्ठ में अगले पृष्ठ और पिछले पृष्ठ पर एक सूचक भी होता है। तो जब आप कोई प्रश्न करते हैं जैसे:
SELECT ID, A
FROM T
WHERE ID > 5
LIMIT 1;
आप एक अद्वितीय अनुक्रमणिका स्कैन कर रहे हैं, इसलिए यह बहुत संभावना है कि यह एक अनुक्रमिक स्कैन होगा। हालांकि इसकी बहुत संभावना नहीं है।
MySQL रूट नोड को स्कैन करेगा, यदि कोई संभावित मैच है तो यह इंटरमीडिएट नोड्स पर चला जाएगा, यदि क्लॉज कुछ इस तरह था WHERE ID < 0 तब MySQL को पता चल जाएगा कि रूट नोड से आगे जाए बिना कोई परिणाम नहीं है।
एक बार जब यह मध्यवर्ती नोड पर चला जाता है तो यह पहचान सकता है कि ID > 5 की खोज शुरू करने के लिए इसे दूसरे पृष्ठ (4 और 7 के बीच) पर प्रारंभ करने की आवश्यकता है . इसलिए यह पहले से ही LIMIT 1 की पहचान कर, दूसरे लीफ पेज से शुरू होने वाले लीफ को क्रमिक रूप से स्कैन करेगा। एक बार मैच मिलने पर यह रुक जाएगा (इस मामले में 6) और इस डेटा को पत्ते से वापस कर दें। ऐसे सरल उदाहरण में यह व्यवहार विश्वसनीय और तार्किक प्रतीत होता है। मैंने एक आईडी मान चुनकर अपवादों को मजबूर करने की कोशिश की है, मुझे पता है कि पत्ते पृष्ठ के अंत में यह देखने के लिए है कि पत्ते को रिवर्स ऑर्डर में स्कैन किया जाएगा, लेकिन अभी तक इस व्यवहार को उत्पन्न करने में असमर्थ रहा है, इसका मतलब यह नहीं है ऐसा नहीं होगा, या MySQL की भविष्य की रिलीज़ मेरे द्वारा परीक्षण किए गए परिदृश्यों में ऐसा नहीं करेगी।
संक्षेप में, बस एक ऑर्डर जोड़ें, या मिन (आईडी) का उपयोग करें और इसके साथ किया जाए। मैं क्वेरी ऑप्टिमाइज़र के आंतरिक कामकाज में तल्लीन करने की कोशिश में बहुत अधिक नींद नहीं खोऊंगा, यह देखने के लिए कि क्वेरी प्लान के भीतर क्लस्टर इंडेक्स के विभिन्न क्रम को देखने के लिए किस प्रकार के विखंडन, या डेटा श्रेणियों की आवश्यकता होगी।
