एक संकुल तालिका "ढेर" भाग के बिना एक बी-ट्री है - पंक्तियों को सीधे क्लस्टरिंग इंडेक्स (प्राथमिक कुंजी) की बी-ट्री संरचना में संग्रहीत किया जाता है। बी-ट्री के नोड्स को विभाजित या समेकित किया जा सकता है, इसलिए भौतिक स्थान या पंक्तियां बदल सकती हैं, इसलिए हमारे पास द्वितीयक इंडेक्स से पंक्तियों तक एक साधारण "पॉइंटर" नहीं हो सकता है, इसलिए सेकेंडरी इंडेक्स में एक पूरी कॉपी शामिल होनी चाहिए पंक्तियों को मज़बूती से पहचानने में सक्षम होने के लिए प्राथमिक अनुक्रमणिका फ़ील्ड।
यह Oracle, MS SQL सर्वर के लिए सही है और InnoDB के लिए भी सही हैए> ।
जिसका मतलब है कि क्लस्टर टेबल में सेकेंडरी इंडेक्स हीप-आधारित टेबल में सेकेंडरी इंडेक्स की तुलना में "फैटर" होते हैं, जो:
- डेटा क्लस्टरिंग को कम करता है,
- कैश की प्रभावशीलता को कम करता है,
- उन्हें बनाए रखने के लिए और अधिक महंगा बनाता है,
- और सबसे महत्वपूर्ण बात, क्वेरी प्रदर्शन पर इसके परिणाम हैं:
- द्वितीयक अनुक्रमणिका के माध्यम से क्वेरी करने के लिए डबल लुकअप की आवश्यकता हो सकती है - "कुंजी" डेटा का पता लगाने के लिए द्वितीयक अनुक्रमणिका के माध्यम से एक लुकअप और प्राथमिक के माध्यम से, स्वयं पंक्ति का पता लगाने के लिए (Oracle के पास दूसरे लुकअप से बचने के लिए कुछ दिलचस्प अनुकूलन हैं, लेकिन मेरी जानकारी में InnoDB नहीं है)।
- दूसरी ओर, द्वितीयक सूचकांक स्वाभाविक रूप से कवर ए> अधिक फ़ील्ड, इसलिए दूसरे लुकअप को पूरी तरह से टाला जा सकता है जहां पारंपरिक ढेर-आधारित इंडेक्स को टेबल एक्सेस की आवश्यकता होगी। हालांकि, ढेर-आधारित अनुक्रमणिका में केवल अधिक फ़ील्ड जोड़कर समान प्रभाव प्राप्त किया जा सकता है।
मुझे यूज़ द इंडेक्स, ल्यूक! :"सूचकांक-संगठित तालिकाओं और संकुल अनुक्रमणिका के लाभ अधिकतर उन तालिकाओं तक सीमित हैं जिन्हें दूसरी अनुक्रमणिका की आवश्यकता नहीं है।"
यह शर्म की बात है, क्योंकि MySQL आपको स्टोरेज इंजन से स्वतंत्र रूप से क्लस्टरिंग चुनने की अनुमति नहीं देता है।