В InnoDB всеки вторичен индекс съдържа вътрешно колоната с първичен ключ на таблицата. И така индексът име на колона (име) имплицитно е на колони (име, id).
Това означава, че EXPLAIN показва вашия достъп до таблицата с категории като "индексно сканиране" (това се показва в type колона като "индекс"). Чрез сканиране на индекса той също има достъп до колоната с id, която използва за търсене на редове във втората таблица, елемент.
След това също се възползва от индекса на елемент на (category_id), който всъщност е (category_id, id), и може да извлече item.id за вашия списък за избор, просто като прочете индекса. Изобщо няма нужда да четете таблицата (това е показано в Extra колона като „Използване на индекс“).
MyISAM не съхранява първичните ключове с вторичния ключ по този начин, така че не може да получи същите оптимизации. Достъпът до таблицата с категории е тип "ВСИЧКИ", което означава сканиране на таблица.
Очаквам достъпът до елемента на таблицата MyISAM да бъде "ref", тъй като търси редове, използвайки индекса на (category_id). Но оптимизаторът може да получи изкривени резултати, ако имате много малко редове в таблицата или ако не сте направили ANALYZE TABLE item от създаването на индекса.
Отново вашата актуализация:
Изглежда, че оптимизаторът предпочита сканиране на индекс пред сканиране на таблица, така че се възползва от възможността да направи сканиране на индекс в InnoDB и поставя таблицата с категории на първо място. Оптимизаторът решава да пренареди таблиците, вместо да използва таблиците в реда, който сте им дали във вашата заявка.
В таблиците на MyISAM ще има едно сканиране на таблица, която таблица избере да осъществи първа, но като постави таблицата на категорията на второ място, тя се присъединява към индекса на ОСНОВНИЯ ключ на категорията вместо към вторичния индекс на елемента. Оптимизаторът предпочита справки пред уникален или първичен ключ (тип "eq_ref").
