Indeks apa yang tampaknya paling logis (semoga jelas, misalnya, kolom ID pelanggan di tabel PELANGGAN).
Kemudian jalankan aplikasi Anda dan kumpulkan statistik secara berkala untuk melihat bagaimana kinerja database. RUNSTATS pada DB2 adalah salah satu contohnya, saya berharap MySQL memiliki alat serupa.
Ketika Anda menemukan beberapa kueri yang sering dijalankan melakukan pemindaian tabel penuh (atau memakan waktu terlalu lama karena alasan lain), maka, dan hanya kemudian , jika Anda menambahkan lebih banyak indeks. Tidak ada gunanya mengoptimalkan kueri yang dijalankan sekali sebulan pada tengah malam sehingga dapat selesai pada 12:05 alih-alih 12:07. Namun, ini adalah peningkatan besar untuk mengurangi kueri yang berhubungan dengan pelanggan dari 5 detik menjadi 2 detik (itu masih terlalu lambat, kueri yang menghadap pelanggan harus kurang dari satu detik jika memungkinkan).
Lebih banyak indeks cenderung memperlambat penyisipan dan mempercepat kueri. Jadi itu selalu merupakan tindakan penyeimbang. Itu sebabnya Anda hanya menambahkan indeks sebagai tanggapan khusus terhadap suatu masalah. Hal lain adalah pengoptimalan prematur dan harus dihindari.
Selain itu, kunjungi kembali indeks yang sudah Anda miliki secara berkala untuk melihat apakah masih diperlukan. Mungkin kueri yang menyebabkan Anda menambahkan indeks tersebut tidak lagi cukup sering dijalankan untuk menjaminnya.
Sejujurnya, saya tidak percaya pengindeksan tiga kolom pada tabel akan menyebabkan Anda menderita kecuali Anda berencana untuk menyimpan jumlah baris yang sangat besar :-) - pengindeksan cukup efisien.
Setelah Anda mengedit yang menyatakan:
Tanggapan saya adalah bahwa 200 catatan sehari adalah nilai yang sangat kecil untuk database, Anda pasti tidak perlu khawatir dengan ketiga indeks tersebut.
Baru minggu ini, saya mengimpor transaksi senilai satu hari ke salah satu tabel database kami di tempat kerja dan berisi 2,1 juta catatan (kami mendapatkan setidaknya satu transaksi per detik sepanjang hari dari 25 mesin terpisah). Dan ia memiliki empat kunci komposit terpisah yang agak lebih intensif daripada tiga kunci individual Anda.
Sekarang memang, itu ada di database DB2 tapi saya tidak bisa membayangkan IBM begitu jauh lebih baik daripada orang-orang MySQL yang MySQL hanya dapat menangani kurang dari 0,01% dari beban DB2.
