Svaret på dette spørgsmål afhænger af, om du bruger mysql før 5.7 eller 5.7 og efter. Jeg ændrer muligvis dit spørgsmål en smule, men forhåbentlig viser det følgende, hvad du leder efter.
Din SELECT * FROM Table laver en tabelscanning via det klyngede indeks (den fysiske bestilling). I tilfælde af ingen primær nøgle, er man implicit
tilgængelig for motoren. Der er ingen hvor-klausul som du siger. Ingen filtrering eller valg af et andet indeks er forsøgt.
Explain
output (se også
) viser 1 række i sin oversigt. Det er relativt ligetil. Forklar output og ydeevne med din afledte tabel B vil variere afhængigt af, om du er på en version før 5.7 eller 5.7 og efter.
Dokumentet Afledte tabeller i MySQL 5.7 beskriver det godt for version 5.6 og 5.7, hvor sidstnævnte ikke vil give nogen straf på grund af ændringen i materialiseret afledt tabeloutput, der er inkorporeret i den ydre forespørgsel. I tidligere versioner blev der udholdt betydelig overhead med midlertidige tabeller med det afledte.
Det er ret nemt at teste præstationsstraffen før 5.7. Det eneste, der skal til, er en mellemstor tabel for at se den mærkbare indvirkning, som dit spørgsmåls afledte tabel har på at påvirke ydeevnen. Følgende eksempel er på en lille tabel 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 |
+----+-------------+-----------------+-------+-----------------+---------+---------+------+-------+----------------------------------------------------+
Bemærk, jeg ændrede spørgsmålet, men det illustrerer den effekt, som afledte tabeller og deres manglende indeksbrug med optimeringsværktøjet har i versioner før 5.7. Den afledte tabel drager fordel af indekser, efterhånden som den bliver materialiseret. Men derefter holder den overhead som en midlertidig tabel og inkorporeres i den ydre forespørgsel uden indeksbrug. Dette er ikke tilfældet i version 5.7