En InnoDB, cualquier índice secundario contiene internamente la columna de clave principal de la tabla. Así que el índice nombre en la columna (nombre) está implícitamente en las columnas (nombre, id).
Esto significa que EXPLAIN muestra su acceso a la tabla de categorías como un "escaneo de índice" (esto se muestra en el tipo columna como "índice"). Al escanear el índice, también tiene acceso a la columna id, que usa para buscar filas en la segunda tabla, elemento.
Luego, también aprovecha el índice de elementos en (category_id) que es realmente (category_id, id), y puede obtener item.id para su lista de selección simplemente leyendo el índice. No es necesario leer la tabla en absoluto (esto se muestra en el Extra columna como "Usando índice").
MyISAM no almacena claves primarias con la clave secundaria de esta manera, por lo que no puede obtener las mismas optimizaciones. El acceso a la tabla de categorías es del tipo "TODOS", lo que significa un escaneo de tabla.
Esperaría que el acceso al elemento de la tabla MyISAM fuera "ref", ya que busca filas usando el índice en (category_id). Pero el optimizador puede obtener resultados sesgados si tiene muy pocas filas en la tabla o si no ha hecho ANALYZE TABLE item desde la creación del índice.
Re su actualización:
Parece que el optimizador prefiere un escaneo de índice sobre un escaneo de tabla, por lo que aprovecha la oportunidad para hacer un escaneo de índice en InnoDB y pone la tabla de categorías primero. El optimizador decide reordenar las tablas en lugar de usar las tablas en el orden que les dio en su consulta.
En las tablas MyISAM, habrá un escaneo de tabla, cualquiera que sea la tabla a la que elija acceder primero, pero al colocar la tabla de categorías en segundo lugar, se une al índice de clave PRIMARIA de la categoría en lugar del índice secundario del elemento. El optimizador prefiere las búsquedas a una clave única o principal (escriba "eq_ref").
