In InnoDB, qualsiasi indice secondario contiene internamente la colonna della chiave primaria della tabella. Quindi l'indice nome su colonna (nome) è implicitamente su colonne (nome, id).
Ciò significa che EXPLAIN mostra il tuo accesso alla tabella delle categorie come una "scansione dell'indice" (questo è mostrato nel tipo colonna come "indice"). Scansionando l'indice, ha anche accesso alla colonna id, che usa per cercare le righe nella seconda tabella, item.
Quindi sfrutta anche l'indice degli elementi su (category_id) che è in realtà (id_categoria, id), ed è in grado di recuperare item.id per la tua lista di selezione semplicemente leggendo l'indice. Non c'è bisogno di leggere la tabella (questo è mostrato in Extra colonna come "Utilizzo dell'indice".
MyISAM non memorizza le chiavi primarie con la chiave secondaria in questo modo, quindi non può ottenere le stesse ottimizzazioni. L'accesso alla tabella delle categorie è di tipo "ALL" che significa una scansione della tabella.
Mi aspetto che l'accesso all'elemento della tabella MyISAM sia "rif" poiché cerca le righe utilizzando l'indice su (categoria_id). Ma l'ottimizzatore potrebbe ottenere risultati distorti se hai pochissime righe nella tabella o se non hai eseguito ANALYZE TABLE item dalla creazione dell'indice.
Riguardo al tuo aggiornamento:
Sembra che l'ottimizzatore preferisca una scansione dell'indice rispetto a una scansione della tabella, quindi coglie l'occasione per eseguire una scansione dell'indice in InnoDB e mette prima la tabella delle categorie. L'ottimizzatore decide di riordinare le tabelle invece di utilizzare le tabelle nell'ordine in cui le hai fornite nella query.
Nelle tabelle MyISAM, ci sarà una scansione della tabella a qualsiasi tabella scelga di accedere per prima, ma inserendo la tabella di categoria per seconda, si unisce all'indice della chiave PRIMARIA della categoria anziché all'indice secondario dell'elemento. L'ottimizzatore preferisce le ricerche a una chiave univoca o primaria (digitare "eq_ref").
