In InnoDB enthält jeder Sekundärindex intern die Primärschlüsselspalte der Tabelle. Also der Index name auf Spalte (Name) ist implizit auf Spalten (Name, ID).
Dies bedeutet, dass EXPLAIN Ihren Zugriff auf die Kategorietabelle als "Index-Scan" anzeigt (dies wird im Typ angezeigt Spalte als "Index"). Durch Scannen des Index hat es auch Zugriff auf die ID-Spalte, die es verwendet, um Zeilen in der zweiten Tabelle, item.
, nachzuschlagenDann nutzt es auch den Elementindex auf (category_id), der eigentlich (category_id, id) ist, und kann item.id für Ihre Auswahlliste abrufen, indem es einfach den Index liest. Sie müssen die Tabelle überhaupt nicht lesen (dies wird im Extra angezeigt Spalte als "Index verwenden").
MyISAM speichert Primärschlüssel nicht auf diese Weise mit dem Sekundärschlüssel, sodass es nicht die gleichen Optimierungen erhalten kann. Der Zugriff auf die Kategorietabelle ist vom Typ "ALL", was einen Tabellen-Scan bedeutet.
Ich würde erwarten, dass der Zugriff auf das MyISAM-Tabellenelement "ref" wäre, da es Zeilen mit dem Index auf (category_id) sucht. Der Optimierer kann jedoch verzerrte Ergebnisse erhalten, wenn Sie sehr wenige Zeilen in der Tabelle haben oder ANALYZE TABLE item nicht ausgeführt haben seit der Indexerstellung.
Bezüglich Ihres Updates:
Es sieht so aus, als würde der Optimierer einen Index-Scan einem Tabellen-Scan vorziehen, also nutzt er die Gelegenheit, um einen Index-Scan in InnoDB durchzuführen, und setzt die Kategorietabelle an die erste Stelle. Der Optimierer beschließt, die Tabellen neu zu ordnen, anstatt die Tabellen in der Reihenfolge zu verwenden, die Sie ihnen in Ihrer Abfrage gegeben haben.
In den MyISAM-Tabellen gibt es einen Tabellen-Scan, unabhängig davon, auf welche Tabelle zuerst zugegriffen wird, aber indem die Kategorietabelle an zweiter Stelle steht, wird sie mit dem PRIMARY-Key-Index der Kategorie verknüpft, anstatt mit dem Sekundärindex des Elements. Der Optimierer bevorzugt Lookups gegenüber einem eindeutigen oder Primärschlüssel (Typ "eq_ref").
