I InnoDB innehåller alla sekundära index internt den primära nyckelkolumnen i tabellen. Alltså indexet namn på kolumn (namn) är implicit på kolumner (namn, id).
Detta betyder att EXPLAIN visar din åtkomst till kategoritabellen som en "index-scan" (detta visas i typ kolumn som "index"). Genom att skanna indexet har den också tillgång till id-kolumnen, som den använder för att slå upp rader i den andra tabellen, item.
Då drar den också nytta av objektindexet på (category_id) som verkligen är (category_id, id), och det kan hämta item.id för din urvalslista genom att helt enkelt läsa indexet. Du behöver inte läsa tabellen alls (detta visas i Extra kolumnen som "Använder index").
MyISAM lagrar inte primärnycklar med sekundärnyckeln på detta sätt, så den kan inte få samma optimeringar. Åtkomsten till kategoritabellen är typ "ALLA", vilket betyder en tabellsökning.
Jag skulle förvänta mig att åtkomsten till MyISAM-tabellobjektet skulle vara "ref" när det letar upp rader med hjälp av indexet på (category_id). Men optimeraren kan få skeva resultat om du har väldigt få rader i tabellen, eller om du inte har gjort ANALYZE TABLE item sedan du skapade indexet.
Om din uppdatering:
Det ser ut som att optimeraren föredrar en index-scan framför en tabell-scan, så den passar på att göra en index-scan i InnoDB och sätter kategoritabellen först. Optimeraren bestämmer sig för att ordna om tabellerna istället för att använda tabellerna i den ordning du gav dem i din fråga.
I MyISAM-tabellerna kommer det att finnas en tabellsökning vilken tabell den än väljer att komma åt först, men genom att placera kategoritabellen på andra plats ansluter den till kategorins PRIMÄRA nyckelindex istället för objektets sekundära index. Optimeraren föredrar uppslagningar framför en unik eller primär nyckel (skriv "eq_ref").