In InnoDB bevat elke secundaire index intern de primaire sleutelkolom van de tabel. Dus de index naam op kolom (naam) staat impliciet op kolommen (naam, id).
Dit betekent dat EXPLAIN uw toegang tot de categorietabel toont als een "index-scan" (dit wordt getoond in het type kolom als "index"). Door de index te scannen, heeft het ook toegang tot de id-kolom, die het gebruikt om rijen op te zoeken in de tweede tabel, item.
Dan profiteert het ook van de itemindex op (category_id) die in werkelijkheid (category_id, id) is, en het kan item.id voor je selectielijst ophalen door simpelweg de index te lezen. U hoeft de tabel helemaal niet te lezen (dit wordt weergegeven in de Extra kolom als "Index gebruiken").
MyISAM slaat op deze manier geen primaire sleutels op met de secundaire sleutel, dus het kan niet dezelfde optimalisaties krijgen. De toegang tot de categorietabel is van het type "ALL", wat een tabelscan betekent.
Ik zou verwachten dat de toegang tot het MyISAM-tabelitem "ref" zou zijn omdat het rijen opzoekt met behulp van de index op (category_id). Maar de optimizer kan scheve resultaten krijgen als u maar heel weinig rijen in de tabel heeft, of als u ANALYZE TABLE item niet heeft gedaan sinds het maken van de index.
Over uw update:
Het lijkt erop dat de optimizer een index-scan verkiest boven een tabel-scan, dus het maakt van de gelegenheid gebruik om een index-scan in InnoDB uit te voeren, en zet de categorietabel als eerste. De optimizer besluit de tabellen opnieuw te ordenen in plaats van de tabellen te gebruiken in de volgorde die u ze in uw zoekopdracht hebt gegeven.
In de MyISAM-tabellen zal er één tabelscan zijn, welke tabel het ook kiest om als eerste te openen, maar door de categorietabel als tweede te plaatsen, voegt het zich bij de PRIMARY-sleutelindex van de categorie in plaats van de secundaire index van het item. De optimizer geeft de voorkeur aan zoekopdrachten boven een unieke of primaire sleutel (type "eq_ref").