Indeks tidak serta merta meningkatkan kinerja. Untuk lebih memahami apa yang terjadi, akan membantu jika Anda menyertakan explain untuk kueri yang berbeda.
Tebakan terbaik saya adalah Anda memiliki indeks di id_state atau bahkan id_state, id_mp yang dapat digunakan untuk memenuhi where ayat. Jika demikian, kueri pertama tanpa order by akan menggunakan indeks ini. Seharusnya cukup cepat. Bahkan tanpa indeks, ini memerlukan pemindaian berurutan halaman dalam orders tabel, yang masih cukup cepat.
Kemudian ketika Anda menambahkan indeks pada creation_date , MySQL memutuskan untuk menggunakan indeks itu sebagai gantinya untuk order by . Ini membutuhkan membaca setiap baris dalam indeks, kemudian mengambil halaman data yang sesuai untuk memeriksa where kondisi dan kembalikan kolom (jika ada kecocokan). Pembacaan ini sangat tidak efisien, karena tidak dalam urutan "halaman" melainkan seperti yang ditentukan oleh indeks. Pembacaan acak bisa sangat tidak efisien.
Lebih buruk lagi, meskipun Anda memiliki limit , Anda masih harus membaca seluruhnya tabel karena seluruh set hasil diperlukan. Meskipun Anda telah menyimpan pengurutan pada 38 catatan, Anda telah membuat kueri yang sangat tidak efisien.
Omong-omong, situasi ini menjadi jauh lebih buruk jika orders tabel tidak sesuai dengan memori yang tersedia. Kemudian Anda memiliki kondisi yang disebut "thrashing", di mana setiap record baru cenderung menghasilkan pembacaan I/O baru. Jadi, jika sebuah halaman memiliki 100 record, halaman tersebut mungkin harus dibaca 100 kali.
Anda dapat membuat semua kueri ini berjalan lebih cepat dengan memiliki indeks pada orders(id_state, id_mp, creation_date) . where klausa akan menggunakan dua kolom pertama dan order by akan menggunakan yang terakhir.
