Отговорът на този въпрос зависи от това дали използвате mysql преди 5.7 или 5.7 и след това. Може леко да променя въпроса ви, но се надявам, че следното ще улови това, което търсите.
Вашият 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
