Het prestatieverschil is mogelijk vanwege e.id_dernier_fichier in de index die wordt gebruikt voor de JOIN, maar e.codega niet in dat . zijn index.
Zonder een volledige definitie van beide tabellen en al hun indexen, is het niet mogelijk om met zekerheid te zeggen. Het zou ook helpen om de twee UITLEGPLANNEN voor de twee vragen op te nemen.
Voor nu kan ik echter een paar dingen nader toelichten...
Als een INDEX GECLUSTERD is (dit geldt ook voor PRIMARY KEYs), worden de gegevens feitelijk fysiek opgeslagen in de volgorde van de INDEX. Dit betekent dat u weet dat u positie x . wilt in de INDEX betekent impliciteit ook dat je positie x . wilt in de TABEL.
Als de INDEX echter niet is geclusterd, biedt de INDEX alleen een zoekopdracht voor u. Effectief zeggen positie x in de INDEX komt overeen met positie y in de TABEL.
Het belang hier is bij toegang tot velden die niet in de INDEX zijn gespecificeerd. Als u dit doet, moet u daadwerkelijk naar de TABEL gaan om de gegevens te krijgen. In het geval van een CLUSTERED INDEX ben je er al, de overhead om dat veld te vinden is vrij laag. Als de INDEX echter niet geclusterd is, moet u in feite de TABEL aan de INDEX toevoegen en vervolgens het veld vinden waarin u geïnteresseerd bent.
Opmerking; Een samengestelde index hebben op (id_dernier_fichier, codega) is heel anders dan één index op slechts (id_dernier_fichier) en een aparte index op slechts (codega) .
In het geval van uw vraag, denk ik niet dat u de code hoeft te wijzigen. Maar je mag profiteer van het wijzigen van de indexen.
Je vermeldt dat je toegang wilt tot veel velden. Al die velden in een samengestelde index plaatsen is waarschijnlijk niet de beste oplossing. In plaats daarvan wilt u misschien een GECLUSTERDE INDEX maken op (id_dernier_fichier) . Dit betekent dat zodra de *id_dernier_fichier* is gevonden, u al op de juiste plaats bent om ook alle andere velden te krijgen.
BEWERKEN Opmerking over MySQL en CLUSTERED INDEXes
13.2.10.1. Geclusterde en secundaire indexen
Elke InnoDB-tabel heeft een speciale index, de geclusterde index genaamd, waar de gegevens voor de rijen worden opgeslagen:
- Als u een PRIMAIRE SLEUTEL op uw tabel definieert, gebruikt InnoDB deze als de geclusterde index.
- Als u geen PRIMARY KEY voor uw tabel definieert, kiest MySQL de eerste UNIEKE index die alleen NOT NULL-kolommen als primaire sleutel heeft en gebruikt InnoDB deze als de geclusterde index.
- Als de tabel geen PRIMAIRE SLEUTEL of geschikte UNIEKE index heeft, genereert InnoDB intern een verborgen geclusterde index op een synthetische kolom met rij-ID-waarden. De rijen zijn geordend op de ID die InnoDB aan de rijen in zo'n tabel toekent. De rij-ID is een veld van 6 bytes dat monotoon toeneemt naarmate nieuwe rijen worden ingevoegd. De rijen die zijn gerangschikt op de rij-ID zijn dus fysiek in invoegvolgorde.