Perbedaan performanya mungkin karena e.id_dernier_fichier berada di indeks yang digunakan untuk GABUNG, tetapi e.codega tidak berada di itu indeks.
Tanpa definisi lengkap dari kedua tabel, dan semua indeksnya, tidak mungkin untuk memastikannya. Juga, menyertakan dua RENCANA JELASKAN untuk dua kueri akan membantu.
Namun, untuk saat ini, saya dapat menguraikan beberapa hal...
Jika INDEX CLUSTERED (ini juga berlaku untuk PRIMARY KEY), data sebenarnya disimpan secara fisik dalam urutan INDEX. Ini berarti mengetahui bahwa Anda menginginkan posisi x di INDEX juga secara implisit berarti Anda ingin posisi x di TABEL.
Namun, jika INDEX tidak berkerumun, INDEX hanya menyediakan pencarian untuk Anda. Secara efektif mengatakan posisi x di INDEX sesuai dengan posisi y di TABEL.
Yang penting di sini adalah saat mengakses bidang yang tidak ditentukan dalam INDEX. Melakukannya berarti Anda harus benar-benar pergi ke TABEL untuk mendapatkan data. Dalam kasus CLUSTERED INDEX, Anda sudah berada di sana, overhead untuk menemukan bidang itu cukup rendah. Namun, jika INDEX tidak dikelompokkan, Anda secara efektif harus MENGGABUNGKAN TABEL ke INDEX, lalu temukan bidang yang Anda minati.
Catatan; Memiliki indeks komposit pada (id_dernier_fichier, codega) sangat berbeda dengan hanya memiliki satu indeks di (id_dernier_fichier) dan indeks terpisah hanya pada (codega) .
Dalam hal permintaan Anda, saya rasa Anda tidak perlu mengubah kode sama sekali. Tapi Anda mungkin manfaat dari mengubah indeks.
Anda menyebutkan bahwa Anda ingin mengakses banyak bidang. Menempatkan semua bidang itu dalam indeks komposit mungkin bukan solusi terbaik. Sebagai gantinya, Anda mungkin ingin membuat CLUSTERED INDEX di (id_dernier_fichier) . Ini berarti bahwa setelah *id_dernier_fichier* ditemukan, Anda juga sudah berada di tempat yang tepat untuk mendapatkan semua bidang lainnya.
EDIT Catatan Tentang MySQL dan CLUSTERED INDEX
13.2.10.1. Indeks Berkelompok dan Sekunder
Setiap tabel InnoDB memiliki indeks khusus yang disebut indeks berkerumun tempat data untuk baris disimpan:
- Jika Anda mendefinisikan PRIMARY KEY di meja Anda, InnoDB menggunakannya sebagai indeks berkerumun.
- Jika Anda tidak mendefinisikan PRIMARY KEY untuk tabel Anda, MySQL memilih indeks UNIK pertama yang hanya memiliki kolom NOT NULL sebagai kunci utama dan InnoDB menggunakannya sebagai indeks berkerumun.
- Jika tabel tidak memiliki PRIMARY KEY atau indeks UNIK yang sesuai, InnoDB secara internal menghasilkan indeks berkerumun tersembunyi pada kolom sintetis yang berisi nilai ID baris. Baris diurutkan berdasarkan ID yang diberikan InnoDB ke baris dalam tabel tersebut. ID baris adalah bidang 6-byte yang meningkat secara monoton saat baris baru dimasukkan. Dengan demikian, baris yang diurutkan oleh ID baris secara fisik dalam urutan penyisipan.
