La differenza di prestazioni è possibile a causa di e.id_dernier_fichier essendo nell'indice utilizzato per il JOIN, ma e.codega non essere in quello indice.
Senza una definizione completa di entrambe le tabelle e di tutti i loro indici, non è possibile dirlo con certezza. Inoltre, sarebbe utile includere i due EXPLAIN PLAN per le due query.
Per ora, però, posso approfondire un paio di cose...
Se un INDEX è CLUSTERED (questo vale anche per le CHIAVI PRIMARIE), i dati vengono effettivamente archiviati fisicamente nell'ordine dell'INDEX. Ciò significa che sapere che vuoi posizione x nell'INDEX anche implicitamente significa che vuoi posizione x nella TABELLA.
Se l'INDEX non è raggruppato, tuttavia, l'INDEX fornisce solo una ricerca per te. Dicendo in modo efficace posizione x nell'INDEX corrisponde alla posizione y nella TABELLA.
L'importanza qui è quando si accede a campi non specificati nell'INDICE. Ciò significa che devi effettivamente andare alla TABELLA per ottenere i dati. Nel caso di un CLUSTERED INDEX, sei già lì, il sovraccarico di trovare quel campo è piuttosto basso. Se l'INDEX non è raggruppato, tuttavia, devi effettivamente UNIRE la TABELLA all'INDEX, quindi trovare il campo che ti interessa.
Nota; Avere un indice composito su (id_dernier_fichier, codega) è molto diverso dall'avere un indice solo su (id_dernier_fichier) e un indice separato solo su (codega) .
Nel caso della tua domanda, non penso che tu debba cambiare affatto il codice. Ma tu puoi trarre vantaggio dalla modifica degli indici.
Dici che vuoi accedere a molti campi. Mettere tutti quei campi in un indice composito probabilmente non è la soluzione migliore. Invece potresti voler creare un CLUSTERED INDEX su (id_dernier_fichier) . Ciò significa che una volta individuato *id_dernier_fichier*, sei già nel posto giusto per ottenere anche tutti gli altri campi.
MODIFICA Nota su MySQL e CLUSTERED INDEX
13.2.10.1. Indici cluster e secondari
Ogni tabella InnoDB ha un indice speciale chiamato indice cluster in cui sono archiviati i dati per le righe:
- Se definisci una CHIAVE PRIMARIA sulla tua tabella, InnoDB la usa come indice cluster.
- Se non definisci una CHIAVE PRIMARIA per la tua tabella, MySQL seleziona il primo indice UNIQUE che ha solo colonne NOT NULL come chiave primaria e InnoDB lo usa come indice cluster.
- Se la tabella non ha PRIMARY KEY o un indice UNIQUE adatto, InnoDB genera internamente un indice cluster nascosto su una colonna sintetica contenente valori ID riga. Le righe sono ordinate in base all'ID che InnoDB assegna alle righe in tale tabella. L'ID riga è un campo di 6 byte che aumenta in modo monotono quando vengono inserite nuove righe. Pertanto, le righe ordinate in base all'ID riga sono fisicamente nell'ordine di inserimento.
