जवाबों:
gen_clust_index (क्लस्टर इंडेक्स) InnoDB के हुड के अंतर्गत rowids के साथ-साथ प्राथमिक कुंजी की प्रविष्टियों घरों। Gen_clust_index के उपयोग के बारे में क्या दिलचस्प है यह तथ्य यह है कि आपके द्वारा बनाए गए किसी भी गैर-अनूठे अनुक्रमणिका में हमेशा एक तालिका के gen_clust_index के लिए एक समान पंक्ति होगी। इस प्रकार, हमेशा दोहरे सूचकांक लुकअप होते हैं, एक द्वितीयक सूचकांक के लिए और एक gen_clust_index के लिए।
किसी तालिका या प्राथमिक कुंजी के लेआउट को बेहतर बनाने के किसी भी प्रयास की वजह से nullified हो जाता है क्योंकि gen_clust_index, या कम से कम सीमांत परिणाम सबसे अच्छे हैं।
उदाहरण
कुछ लोग प्राथमिक कुंजी क्रम में एक MyISAM को सॉर्ट करने का प्रयास करते हैं। MySQL डाटाबेस डिजाइन और ट्यूनिंग के अनुसार , पृष्ठ 236 अनुच्छेद 7, अधीनता के तहत "इंडेक्स ऑर्डर में एक तालिका संग्रहीत करना":
यदि आप बार-बार किसी तालिका से अनुक्रमित डेटा की बड़ी श्रेणियों को प्राप्त करते हैं या एक ही सूचकांक कुंजी पर लगातार परिणामों को सॉर्ट करते हैं, तो आप --isort- रिकॉर्ड विकल्प के साथ myisamchk को चलाने पर विचार कर सकते हैं। ऐसा करने से MySQL को तालिका के डेटा को इंडेक्स के समान भौतिक क्रम में सॉर्ट करने के लिए कहा जाता है, और इस प्रकार के संचालन को गति देने में मदद कर सकता है। वैकल्पिक रूप से, आप समान परिणाम प्राप्त करने के लिए किसी विशेष कॉलम विकल्प के साथ ORDER के साथ ALTER TABLE स्टेटमेंट को जोड़ सकते हैं।
दी, यह MyISAM के लिए प्रभावी रूप से काम करता है और करता है । आप ALB TABLE ... ORDER BY col1, col2, ... का प्रदर्शन कर सकते हैं, InnoDB के खिलाफ कॉलन जहां कॉलम PRIMARY KEY का हो भी सकता है और नहीं भी। यह InnoDB के लिए तेज़ी से परिणाम नहीं देगा क्योंकि ... यह सही है ... आपको हर बार gen_clust_index से परामर्श करना चाहिए।
कुछ लोग तालिका के पंक्ति प्रारूप का उपयोग करके FIXED बना ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;सकते हैं और बिना किसी अन्य परिवर्तन के रीड प्रदर्शन में 20% की वृद्धि प्राप्त कर सकते हैं। यह MyISAM के लिए प्रभावी रूप से काम करता है और करता है । यह InnoDB के लिए तेज़ी से परिणाम नहीं देगा क्योंकि ... यह सही है ... आपको हर बार gen_clust_index से परामर्श करना चाहिए।
आप mydb.mytb नाम की एक InnoDB तालिका पर निम्नलिखित प्रदर्शन कर सकते हैं:
CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;यह तालिका को वंशावली क्रम में gen_clust_index में डाल देगा। यह InnoDB के लिए सर्वोत्तम परिणाम प्राप्त कर सकता है क्योंकि ... यह सही है ... आपको हर बार gen_clust_index से परामर्श करना चाहिए।
अब, थोड़ा हास्यास्पद होने दो। क्वेरी करने के लिए एक NoSQL इंटरफ़ेस है (केवल चयन करें) MyISAM और InnoDB को हैंडलर सॉकेट (पूर्व में HANLDER) इंटरफ़ेस कहा जाता है । यह आपको डेटा तक पहुंच प्रदान करता है जो आपको सभी SQL, ACID और MVCC प्रोटोकॉल को बायपास करने देता है। यद्यपि यह संभव है, IMHO WAY TOO COMPLICATED TO CODE और MAINTAIN। AFAIK में ऐसा कुछ भी नहीं है जो बताता है कि हैंडलर सॉकेट इंटरफ़ेस gen_clust_index के साथ इंटरैक्ट करता है या नहीं।
सारांश में, एक बिल्ली की त्वचा के कई तरीके हैं। इस स्थिति में, आपको बिल्ली (gen_clust_index) की पकड़ नहीं मिल सकती है। मुझे लगता है यही कारण है कि MyISAM अपने रीड परफॉर्मेंस, टेबल ऑर्डरिंग, टेबल रो फॉर्मेट, और इसके समर्थन में टूल्स के लिए अपनी कार्यक्षमता के लिए मौजूद है। InnoDB अपने ACID-अनुरूप प्रकृति के आसपास डिज़ाइन किया जाएगा, जब तक कि कुछ बहादुर आत्मा InnoDB स्रोत कोड नहीं लेती है और इसे कुछ ऐसे में बदल देती है, जिसमें MyISAM और InnoDB दोनों का सर्वश्रेष्ठ है ।
संकुल अनुक्रमणिका शायद पारंपरिक स्पिन ड्राइव पर InnoDB के संगामिति प्रदर्शन के लिए कारण।
क्लस्टर इंडेक्स के माध्यम से एक पंक्ति तक पहुंचना तेज है क्योंकि पंक्ति डेटा उसी पृष्ठ पर है जहां सूचकांक खोज की ओर जाता है। यदि कोई तालिका बड़ी है, तो संकुल अनुक्रमणिका आर्किटेक्चर अक्सर स्टोरेज संगठनों की तुलना में डिस्क I / O ऑपरेशन को बचाता है जो इंडेक्स रिकॉर्ड से भिन्न पृष्ठ का उपयोग करके पंक्ति डेटा को संग्रहीत करता है। (उदाहरण के लिए, MyISAM डेटा पंक्तियों के लिए एक फ़ाइल और इंडेक्स रिकॉर्ड के लिए दूसरा उपयोग करता है।)
डिस्क I / O महंगा है। इसलिए संक्षिप्तता को बेहतर बनाने के लिए यह कम करना एक बहुत बड़ा लाभ है।
यदि डिस्क I / O सस्ती और अड़चन से कम होने लगती है (जैसे, SSD तकनीक अधिक स्थिर हो जाती है), तो Oracle इनोबीडी इंडेक्स कैसे काम करता है, इसे बदलने का निर्णय ले सकता है। अधिक संभावना है कि यह एक ही रहेगा, क्योंकि एक ही तकनीक 'रैम की सीमा' को एक मुद्दे से कम कर देगी।
संक्षिप्त उत्तर: नहीं।
प्राथमिक कुंजी के माध्यम से InnoDB क्लस्टर, और प्राथमिक कुंजी की अनुपस्थिति में, यह पहला अद्वितीय सूचकांक चुनता है। एक अद्वितीय सूचकांक की अनुपस्थिति में, यह क्लस्टरिंग के लिए एक छिपी 6 बाइट कुंजी बनाता है।
जब आपके पास छिपी हुई 6 बाइट कुंजी होती है, तो कोई भी द्वितीयक इंडेक्स इस कुंजी को संदर्भित करता है, बजाय पंक्ति स्थान (MyISAM में) के लिए सटीक संकेत की तुलना में, इसलिए आप एक द्वितीयक कुंजी ट्रैवर्सल के साथ समाप्त होते हैं, और फिर अपने रिकॉर्ड को खोजने के लिए एक प्राथमिक कुंजी ट्रैवर्सल। ।
आपके प्रश्न से थोड़ा अलग होने के लिए, मैं मान रहा हूं कि आप एक पेड़ के साथ मेमोरी फिट के बारे में चिंतित हैं, क्योंकि कुशलतापूर्वक खोज करने के लिए, सभी रूट नोड्स को स्मृति में होना चाहिए, क्योंकि आपको हमेशा अपने पत्ती के पन्नों को खोजने के लिए इस रास्ते पर चलना होगा?
यह सच है, लेकिन एक सांत्वना यह है कि वाणिज्यिक डेटाबेस कोशिश करते हैं और अपने पेड़ों को जितना संभव हो उतना गहरा बनाने के बजाय वसा बनाते हैं। देखने के लिए अपने डेटा पर xtrabackup --stats चलाने का प्रयास करें । उदाहरण के लिए:
<INDEX STATISTICS>
table: test/table1, index: PRIMARY, space id: 12, root page 3
estimated statistics in dictionary:
key vals: 25265338, leaf pages 497839, size pages 498304
real statistics:
level 2 pages: pages=1, data=5395 bytes, data/pages=32%
level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%497839 पत्ती पृष्ठ (~ 8 जीबी) थे, लेकिन केवल 416 पृष्ठ ऊपर (6.5 एमबी)। मैंने इस आदेश को उत्पादन डेटा पर कुछ बार चलाया है, और यह हमेशा मुझे आश्चर्यचकित करता है जब मेरे पास लाखों-अरबों रिकॉर्ड होते हैं, और केवल 1-3 पृष्ठ + पत्ती पृष्ठ होते हैं।