Svaret på denna fråga beror på om du använder mysql före 5.7 eller 5.7 och efter. Jag kanske ändrar din fråga något, men förhoppningsvis fångar följande vad du är ute efter.
Din SELECT * FROM Table gör en tabellskanning via det klustrade indexet (den fysiska beställningen). Om det inte finns någon primärnyckel är en implicit
tillgänglig för motorn. Det finns ingen varklausul som du säger. Ingen filtrering eller val av annat index har gjorts.
Explain
utdata (se även
) visar 1 rad i sin sammanfattning. Det är relativt rakt fram. Förklara utdata och prestanda med din härledda tabell B kommer att skilja sig beroende på om du använder en version före 5.7 eller 5.7 och senare.
Dokumentet Härledda tabeller i MySQL 5.7 beskriver det väl för versionerna 5.6 och 5.7, där den senare inte ger någon påföljd på grund av att förändringen i materialiserad härledd tabellutdata införlivas i den yttre frågan. I tidigare versioner uthärdades betydande omkostnader med tillfälliga tabeller med det härledda.
Det är ganska enkelt att testa prestationsstraffet före 5.7. Allt som krävs är en medelstor tabell för att se den märkbara inverkan som din frågas härledda tabell har på prestandan. Följande exempel finns på en liten tabell i version 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 |
+----+-------------+-----------------+-------+-----------------+---------+---------+------+-------+----------------------------------------------------+
Observera att jag ändrade frågan, men den illustrerar effekten som härledda tabeller och deras brist på indexanvändning med optimeraren har i versioner före 5.7. Den härledda tabellen drar nytta av index när den materialiseras. Men därefter uthärdar den overhead som en tillfällig tabell och införlivas i den yttre frågan utan indexanvändning. Detta är inte fallet i version 5.7