Saya juga berasumsi Anda menggunakan Oracle. Dan saya juga menyarankan Anda untuk memeriksa halaman web rencana penjelasan, sebagai permulaan. Ada banyak hal yang perlu dioptimalkan, tetapi dapat dipelajari.
Beberapa tips berikut:
Pertama, ketika seseorang menugaskan Anda untuk mengoptimalkan, mereka hampir selalu mencari kinerja yang dapat diterima daripada kinerja akhir. Jika Anda dapat mengurangi waktu berjalan kueri dari 3 menit menjadi 3 detik, jangan khawatir untuk menguranginya menjadi 2 detik, sampai Anda diminta.
Kedua, lakukan pemeriksaan cepat untuk memastikan kueri yang Anda optimalkan sudah benar secara logis. Kedengarannya tidak masuk akal, tetapi saya tidak dapat memberi tahu Anda berapa kali saya dimintai nasihat tentang kueri yang berjalan lambat, hanya untuk mengetahui bahwa itu kadang-kadang memberikan jawaban yang salah! Dan ternyata, men-debug kueri sering kali juga mempercepatnya.
Secara khusus, cari frasa "Cartesian Join" dalam rencana penjelasan. Jika Anda melihatnya di sana, kemungkinan besar Anda telah menemukan gabungan kartesius yang tidak disengaja. Pola umum untuk gabungan kartesius yang tidak disengaja adalah bahwa klausa FROM mencantumkan tabel yang dipisahkan oleh koma, dan kondisi gabungan berada dalam klausa WHERE. Kecuali salah satu kondisi join tidak ada, sehingga Oracle tidak punya pilihan selain melakukan cartesian join. Dengan tabel besar, ini adalah bencana kinerja.
Dimungkinkan untuk melihat Gabung Cartesian dalam rencana penjelasan di mana kueri secara logis benar, tetapi saya mengaitkan ini dengan versi Oracle yang lebih lama.
Cari juga indeks senyawa yang tidak digunakan. Jika kolom pertama dari indeks gabungan tidak digunakan dalam kueri, Oracle dapat menggunakan indeks secara tidak efisien, atau tidak sama sekali. Saya beri contoh:
Pertanyaannya adalah:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(DBMS bukan Oracle, jadi sintaksnya berbeda, dan saya lupa sintaks aslinya).
Mengintip cepat pada indeks mengungkapkan indeks pada Pelanggan dengan kolom (Negara, Negara Bagian, Kode Pos) dalam urutan itu. Saya mengubah kueri untuk membaca
select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
dan sekarang berjalan dalam waktu sekitar 6 detik, bukan sekitar 6 menit, karena pengoptimal dapat menggunakan indeks untuk keuntungan yang baik. Saya bertanya kepada pemrogram aplikasi mengapa mereka menghilangkan negara dari kriteria, dan ini adalah jawaban mereka:mereka tahu bahwa semua alamat memiliki negara yang sama dengan 'USA' sehingga mereka pikir mereka dapat mempercepat kueri dengan mengabaikan kriteria itu!
Sayangnya, mengoptimalkan pengambilan basis data tidak benar-benar sama dengan memangkas waktu komputasi mikrodetik. Ini melibatkan pemahaman desain database, terutama indeks, dan setidaknya gambaran tentang bagaimana pengoptimal melakukan tugasnya.
Anda biasanya mendapatkan hasil yang lebih baik dari pengoptimal saat Anda belajar berkolaborasi dengannya daripada mencoba mengakalinya.
Semoga berhasil mempercepat pengoptimalan!
