W InnoDB każdy indeks pomocniczy wewnętrznie zawiera kolumnę klucza podstawowego tabeli. Tak więc indeks nazwa w kolumnie (nazwa) jest domyślnie w kolumnach (nazwa, id).
Oznacza to, że EXPLAIN pokazuje Twój dostęp do tabeli kategorii jako „skanowanie indeksu” (jest to pokazane w typu kolumna jako „indeks”). Skanując indeks, ma również dostęp do kolumny id, której używa do wyszukiwania wierszy w drugiej tabeli, element.
Następnie korzysta również z indeksu pozycji on (category_id), który tak naprawdę jest (category_id, id) i jest w stanie pobrać item.id dla twojej listy wyboru, po prostu czytając indeks. W ogóle nie trzeba czytać tabeli (jest to pokazane w Dodatku kolumna jako "Korzystanie z indeksu").
MyISAM nie przechowuje kluczy podstawowych z kluczem pomocniczym w ten sposób, więc nie może uzyskać tych samych optymalizacji. Dostęp do tabeli kategorii jest typu „WSZYSTKO”, co oznacza skanowanie tabeli.
Spodziewałbym się, że dostęp do elementu tabeli MyISAM będzie "ref", ponieważ wyszukuje wiersze przy użyciu indeksu na (category_id). Optymalizator może jednak uzyskać przekrzywione wyniki, jeśli masz bardzo mało wierszy w tabeli lub jeśli nie wykonałeś elementu ANALYZE TABLE item od czasu utworzenia indeksu.
Ponowna aktualizacja:
Wygląda na to, że optymalizator woli skanowanie indeksu od skanowania tabeli, więc wykorzystuje okazję do skanowania indeksu w InnoDB i umieszcza tabelę kategorii na pierwszym miejscu. Optymalizator postanawia zmienić kolejność tabel zamiast używać ich w kolejności podanej w zapytaniu.
W tabelach MyISAM będzie jedna tabela-skanować tę tabelę, do której wybierze dostęp jako pierwszą, ale umieszczając tabelę kategorii jako drugą, łączy się ona z indeksem klucza PRIMARY kategorii zamiast z indeksem drugorzędnym elementu. Optymalizator preferuje wyszukiwania do klucza unikalnego lub podstawowego (wpisz "eq_ref").
