Dans InnoDB, tout index secondaire contient en interne la colonne de clé primaire de la table. Donc l'index nom on column (name) est implicitement sur les colonnes (name, id).
Cela signifie qu'EXPLAIN affiche votre accès à la table des catégories sous la forme d'un "index-scan" (ceci est affiché dans le type colonne comme "index"). En parcourant l'index, il a également accès à la colonne id, qu'il utilise pour rechercher des lignes dans la deuxième table, item.
Ensuite, il tire également parti de l'index d'élément sur (category_id) qui est vraiment (category_id, id), et il est capable de récupérer item.id pour votre liste de sélection simplement en lisant l'index. Pas besoin de lire le tableau du tout (ceci est indiqué dans l'Extra colonne comme "Utilisation de l'index").
MyISAM ne stocke pas les clés primaires avec la clé secondaire de cette manière, il ne peut donc pas obtenir les mêmes optimisations. L'accès à la table des catégories est de type "TOUT" ce qui signifie un parcours de table.
Je m'attendrais à ce que l'accès à l'élément de table MyISAM soit "ref" car il recherche des lignes en utilisant l'index sur (category_id). Mais l'optimiseur peut obtenir des résultats faussés si vous avez très peu de lignes dans la table, ou si vous n'avez pas fait ANALYZE TABLE item depuis la création de l'index.
Concernant votre mise à jour :
Il semble que l'optimiseur préfère une analyse d'index à une analyse de table, il en profite donc pour effectuer une analyse d'index dans InnoDB et place la table de catégories en premier. L'optimiseur décide de réorganiser les tables au lieu d'utiliser les tables dans l'ordre que vous leur avez donné dans votre requête.
Dans les tables MyISAM, il y aura une analyse de table quelle que soit la table à laquelle elle choisit d'accéder en premier, mais en plaçant la table de catégorie en second, elle se joint à l'index de clé PRIMARY de la catégorie au lieu de l'index secondaire de l'élément. L'optimiseur préfère les recherches à une clé unique ou primaire (type "eq_ref").
