Skillnaden i prestanda är möjligen på grund av e.id_dernier_fichier finns i indexet som används för JOIN, men e.codega inte vara i det index.
Utan en fullständig definition av båda tabellerna och alla deras index är det inte möjligt att säga säkert. Det skulle också hjälpa att inkludera de två EXPLAIN-PLANerna för de två frågorna.
För nu kan jag dock utveckla ett par saker...
Om ett INDEX är KLUSTERAT (detta gäller även PRIMÄRA NYCKLAR) lagras data faktiskt fysiskt i ordningen för INDEX. Det betyder att du vet att du vill ha position x i INDEX betyder implicit också att du vill ha position x i TABELL.
Om INDEX inte är klustrat, ger INDEX bara en uppslag åt dig. Säger effektivt position x i INDEX motsvarar position y i TABELL.
Vikten här är när man kommer åt fält som inte är specificerade i INDEX. Att göra det innebär att du faktiskt måste gå till TABELLEN för att få informationen. I fallet med ett CLUSTERED INDEX, är du redan där, omkostnaden för att hitta det fältet är ganska låg. Om INDEX inte är klustrat, måste du dock GÅ MED TABELL till INDEX och sedan hitta fältet du är intresserad av.
Notera; Att ha ett sammansatt index på (id_dernier_fichier, codega) skiljer sig mycket från att ha ett index på bara (id_dernier_fichier) och ett separat index på bara (codega) .
När det gäller din fråga tror jag inte att du behöver ändra koden alls. Men du kan dra nytta av att ändra indexen.
Du nämner att du vill komma åt många fält. Att sätta alla dessa fält i ett sammansatt index är förmodligen inte den bästa lösningen. Istället kanske du vill skapa ett CLUSTERED INDEX på (id_dernier_fichier) . Detta kommer att innebära att när *id_dernier_fichier* har hittats är du redan på rätt plats för att få alla andra fält också.
REDIGERA Anmärkning om MySQL och CLUSTERED INDEX
13.2.10.1. Klustrade och sekundära index
Varje InnoDB-tabell har ett speciellt index som kallas det klustrade indexet där data för raderna lagras:
- Om du definierar en PRIMÄRNYCKEL på din tabell, använder InnoDB den som det klustrade indexet.
- Om du inte definierar en PRIMÄRNYCKEL för din tabell, väljer MySQL det första UNIKA indexet som endast har INTE NULL-kolumner som primärnyckel och InnoDB använder det som det klustrade indexet.
- Om tabellen inte har någon PRIMÄRNYCKEL eller lämpligt UNIKT index, genererar InnoDB internt ett dolt klustrat index på en syntetisk kolumn som innehåller rad-ID-värden. Raderna är ordnade efter det ID som InnoDB tilldelar raderna i en sådan tabell. Rad-ID är ett 6-byte-fält som ökar monotont när nya rader infogas. Således är raderna ordnade av rad-ID:t fysiskt i infogningsordning.