I InnoDB indeholder ethvert sekundært indeks internt den primære nøglekolonne i tabellen. Altså indekset navn på kolonne (navn) er implicit på kolonner (navn, id).
Det betyder, at EXPLAIN viser din adgang til kategoritabellen som en "indeks-scanning" (dette er vist i typen kolonne som "indeks"). Ved at scanne indekset har den også adgang til id-kolonnen, som den bruger til at slå rækker op i den anden tabel, item.
Så udnytter den også vareindekset på (category_id), som egentlig er (category_id, id), og den er i stand til at hente item.id til din select-list blot ved at læse indekset. Det er ikke nødvendigt at læse tabellen overhovedet (dette er vist i Ekstra). kolonne som "Bruger indeks").
MyISAM gemmer ikke primærnøgler med den sekundære nøgle på denne måde, så den kan ikke få de samme optimeringer. Adgangen til kategoritabellen er typen "ALL", hvilket betyder en tabelscanning.
Jeg ville forvente, at adgangen til MyISAM-tabelelementet ville være "ref", da det slår rækker op ved hjælp af indekset på (category_id). Men optimeringsværktøjet kan få skæve resultater, hvis du har meget få rækker i tabellen, eller hvis du ikke har udført ANALYZE TABLE item siden oprettelsen af indekset.
Om din opdatering:
Det ser ud til, at optimizeren foretrækker en indeks-scanning frem for en tabel-scanning, så den benytter lejligheden til at lave en indeks-scanning i InnoDB, og sætter kategoritabellen først. Optimeringsværktøjet beslutter at omarrangere tabellerne i stedet for at bruge tabellerne i den rækkefølge, du gav dem i din forespørgsel.
I MyISAM-tabellerne vil der være én tabel-scanning, hvilken tabel den vælger at få adgang til først, men ved at sætte kategoritabellen som nummer to, forbindes den med kategoriens PRIMÆRE nøgleindeks i stedet for elementets sekundære indeks. Optimeringsværktøjet foretrækker opslag frem for en unik eller primær nøgle (skriv "eq_ref").