इस प्रश्न का उत्तर इस बात पर निर्भर करता है कि आप 5.7 से पहले या 5.7 और बाद में mysql का उपयोग कर रहे हैं। हो सकता है कि मैं आपके प्रश्न में थोड़ा बदलाव कर रहा हूं, लेकिन उम्मीद है कि आप जो चाहते हैं, वह निम्नलिखित है।
आपका SELECT * FROM Table क्लस्टर्ड इंडेक्स (भौतिक क्रम) के माध्यम से एक टेबल स्कैन करता है। प्राथमिक कुंजी नहीं होने की स्थिति में, एक है निहित रूप से
इंजन के लिए उपलब्ध है। जैसा कि आप कहते हैं, वहां कोई खंड नहीं है। किसी अन्य अनुक्रमणिका को फ़िल्टर करने या चुनने का प्रयास नहीं किया जाता है।
स्पष्ट करें
आउटपुट (देखें भी
) इसके सारांश में 1 पंक्ति दिखाता है। यह अपेक्षाकृत सीधे आगे है। अपनी व्युत्पन्न तालिका के साथ आउटपुट और प्रदर्शन की व्याख्या करें B यह इस बात पर निर्भर करेगा कि आप 5.7 से पहले के संस्करण पर हैं या 5.7 और बाद के संस्करण पर हैं।
दस्तावेज़ MySQL 5.7 में व्युत्पन्न तालिकाएं संस्करण 5.6 और 5.7 के लिए इसका अच्छी तरह से वर्णन करता है, जहां बाद वाले बाहरी क्वेरी में शामिल किए जा रहे भौतिक व्युत्पन्न तालिका आउटपुट में परिवर्तन के कारण कोई दंड नहीं देंगे। पिछले संस्करणों में, व्युत्पन्न के साथ अस्थायी तालिकाओं के साथ पर्याप्त ओवरहेड सहन किया गया था।
5.7 से पहले प्रदर्शन दंड का परीक्षण करना काफी आसान है। आपके प्रश्न की व्युत्पन्न तालिका का प्रदर्शन को प्रभावित करने वाले ध्यान देने योग्य प्रभाव को देखने के लिए केवल एक मध्यम आकार की तालिका की आवश्यकता होती है। निम्न उदाहरण संस्करण 5.6 में एक छोटी तालिका पर है:
explain
select qm1.title
from questions_mysql qm1
join questions_mysql qm2
on qm2.qid<qm1.qid
where qm1.qid>3333 and qm1.status='O';
+----+-------------+-------+-------+-----------------+---------+---------+------+-------+------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+-----------------+---------+---------+------+-------+------------------------------------------------+
| 1 | SIMPLE | qm1 | range | PRIMARY,cactus1 | PRIMARY | 4 | NULL | 5441 | Using where |
| 1 | SIMPLE | qm2 | ALL | PRIMARY,cactus1 | NULL | NULL | NULL | 10882 | Range checked for each record (index map: 0x3) |
+----+-------------+-------+-------+-----------------+---------+---------+------+-------+------------------------------------------------+
explain
select b.title from
( select qid,title from questions_mysql where qid>3333 and status='O'
) b
join questions_mysql qm2
on qm2.qid<b.qid;
+----+-------------+-----------------+-------+-----------------+---------+---------+------+-------+----------------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------------+-------+-----------------+---------+---------+------+-------+----------------------------------------------------+
| 1 | PRIMARY | qm2 | index | PRIMARY,cactus1 | cactus1 | 10 | NULL | 10882 | Using index |
| 1 | PRIMARY | <derived2> | ALL | NULL | NULL | NULL | NULL | 5441 | Using where; Using join buffer (Block Nested Loop) |
| 2 | DERIVED | questions_mysql | range | PRIMARY,cactus1 | PRIMARY | 4 | NULL | 5441 | Using where |
+----+-------------+-----------------+-------+-----------------+---------+---------+------+-------+----------------------------------------------------+
ध्यान दें, मैंने प्रश्न बदल दिया है, लेकिन यह उस प्रभाव को दिखाता है जो व्युत्पन्न तालिकाओं और ऑप्टिमाइज़र के साथ इंडेक्स उपयोग की कमी 5.7 से पहले के संस्करणों में है। व्युत्पन्न तालिका अनुक्रमित से लाभान्वित होती है क्योंकि इसे भौतिक किया जा रहा है। लेकिन उसके बाद यह एक अस्थायी तालिका के रूप में ओवरहेड को सहन करता है और बिना इंडेक्स उपयोग के बाहरी क्वेरी में शामिल किया जाता है। संस्करण 5.7 में ऐसा नहीं है
