Para ahli tahu cara menulis kueri yang efisien kinerja. Meskipun pengalaman mematangkan kebijaksanaan, ada hal-hal tertentu yang harus dipahami setidaknya untuk memulai. Misalnya, Anda harus memahami pertimbangan utama desain kueri; bagaimana kinerja kueri secara internal, di mana gagal, pola pengoptimalan, dll. Dalam artikel ini, saya akan memberikan beberapa poin pengoptimalan untuk direnungkan saat merancang kueri di MySQL.
Mengapa Beberapa Kueri Lambat?
Masalah umum dengan kueri SQL adalah lebih banyak data yang diambil daripada yang sebenarnya dibutuhkan. Tentu saja, ada kueri yang menyaring banyak data dan kami tidak bisa berbuat banyak tentangnya, tetapi itu tidak umum. Dalam kebanyakan kasus, desain kueri yang buruk menyebabkan kinerja kueri yang buruk. Setelah setiap desain kueri, Anda harus mengintrospeksi beberapa aspek seperti apa yang bisa terjadi setelah kueri diaktifkan:
- Apakah kueri SQL akan mengakses terlalu banyak kolom atau baris?
- Apakah server MySQL akan menganalisis terlalu banyak baris untuk mendapatkan hasil yang diinginkan?
Ada kueri yang membuat server MySQL menganalisis terlalu banyak data tetapi membuangnya saat disaring. Ini adalah pekerjaan ekstra untuk server dalam hal banyak aspek seperti overhead jaringan, terlalu banyak konsumsi memori atau terlalu banyak penggunaan sumber daya CPU di server. Konsekuensinya adalah kinerja yang lambat.
Ada situasi di mana Anda mungkin tidak dapat membantu banyak selama desainnya, tetapi ada situasi di mana jika Anda berhati-hati dan memperkirakan konsekuensi dan introspeksi, maka kueri yang buruk setidaknya dapat menjadi baik jika tidak lebih baik.
Kesalahan Umum dan Solusinya
Ada beberapa kesalahan umum yang sering dilakukan saat menulis kueri. Berikut adalah beberapa di antaranya. Anda dapat menemukan beberapa pemikiran lagi pada baris yang sama. Berikut alasan kinerja kueri yang lambat dengan solusi yang memungkinkan.
Terlalu banyak baris
Kesalahan sering dibuat saat menulis kueri yang mengambil data dan menganggap bahwa MySQL akan memberikan hasil sesuai permintaan sambil mengabaikan jumlah pemrosesan yang diperlukan untuk mengembalikan set hasil lengkap. Misalkan, pernyataan SELECT diaktifkan untuk mengambil 100 detail produk untuk situs e-niaga ketika hanya 10 di antaranya yang benar-benar perlu ditampilkan terlebih dahulu. Anda mungkin berpikir bahwa MySQL hanya mengambil 10 baris dan berhenti mengeksekusi kueri. Tapi tidak. Apa yang dilakukan MySQL adalah menghasilkan set hasil lengkap dan memberi makan klien. Pustaka klien menerima set lengkap dan membuang sebagian besar dan hanya menyimpan 10 yang dicari. Ini jelas membuang banyak sumber daya.
Namun, dalam situasi seperti itu, Anda dapat memberikan solusi dengan menggunakan klausa LIMIT dengan kueri.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
Klausa LIMIT menerima satu atau dua parameter. Yang pertama menentukan offset, dan yang kedua menentukan jumlah. Jika hanya satu parameter yang ditentukan, ini menunjukkan jumlah baris dari awal kumpulan hasil.
Misalnya, untuk memilih 10 baris dari tabel, Anda dapat menulis:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
Dan untuk memilih 10 baris berikutnya, mulai dari 11 record, Anda dapat menulis:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Terlalu banyak Kolom
Selalu lihat kueri:SELECT * dengan curiga. Kueri ini mengembalikan semua kolom dan Anda mungkin hanya memerlukan beberapa di antaranya. Kerugian terbesar dari mengambil semua kolom adalah mencegah pengoptimalan dengan menghalangi penggunaan indeks, menuntut terlalu banyak I/O, memori, dan sumber daya CPU dari server.
Pahami bahwa kueri universal seperti itu yang mengambil semua kolom bisa jadi sia-sia. Beberapa mengatakan mereka berguna karena memungkinkan pengembang menggunakan sedikit kode yang sama di lebih dari satu tempat. Tidak apa-apa jika biaya yang terlibat terbatas dalam pertimbangan. Terkadang caching data yang diambil membantu dalam konteks ini. Namun berhati-hatilah, meningkatkan kinerja adalah pekerjaan yang bagus dan kemewahan seperti itu mungkin tidak cocok untuk kinerja.
Aturan praktisnya adalah untuk menghindari kueri universal seperti itu atau menjaga jumlah kolom yang diambil seminimal mungkin.
Terlalu banyak analisis data
Kueri mengembalikan hasil yang diinginkan yang baik-baik saja tetapi terkadang kueri ini ditulis sedemikian rupa sehingga saat memprosesnya memerlukan pemeriksaan terlalu banyak data sebelum menghasilkan hasil. Oleh karena itu, di MySQL Anda harus mengukur menurut metrik biaya berikut:
- Waktu eksekusi
- Baris diperiksa
- Kolom diperiksa
Anda bisa mendapatkan perkiraan kasar biaya kueri dari metrik ini. Ini mencerminkan jumlah akses data oleh MySQL secara internal untuk memproses kueri dan seberapa cepat kueri berjalan. Karena metrik ini dicatat dalam log kueri lambat, ada baiknya untuk menyelidiki dan menemukan kueri yang menganalisis terlalu banyak data untuk mengembalikan hasilnya. Database MySQL mendaftarkan semua kueri yang melebihi jumlah waktu eksekusi tertentu dalam log kueri lambat. Ini tempat yang ideal untuk mencari kueri lambat dan mengetahui seberapa sering kueri lambat.
Log kueri lambat biasanya terletak di /var/log/mysql/mysql-slow.log
Perhatikan bahwa, seseorang mungkin harus menyetel dan mengaktifkan pencatatan kueri lambat di mysqld.cnf file konfigurasi sebagai berikut.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Sebelum dan dengan MySQL 5 ada batasan serius terutama kurangnya dukungan untuk logging berbutir halus. Hanya jeda yang menggunakan tambalan yang mengaktifkan logging. Namun, fitur tersebut telah menjadi bagian dari MySQL 5.1 dan server yang lebih baru sebagai bagian dari fitur intinya.
Kueri yang membutuhkan terlalu banyak waktu dalam eksekusi tidak selalu berarti itu adalah kueri yang buruk. Log kueri yang lambat hanya memberikan kesempatan untuk memeriksa kinerja kueri dan meningkatkannya sebaik mungkin.
Merestrukturisasi kueri
Karena Anda memiliki kesempatan untuk menyusun ulang pertanyaan yang bermasalah, tujuan utama Anda seharusnya adalah menemukan solusi alternatif untuk mencapai efek yang kita inginkan. Anda dapat mengubah kueri menjadi bentuk yang setara dengan mengingat efek internal di server MySQL saat memproses.
Salah satu keputusan dalam desain kueri adalah apakah kita harus memilih satu kueri kompleks sebagai ganti beberapa kueri sederhana atau sebaliknya. Pendekatan konvensional dari desain database adalah melakukan pekerjaan sebanyak mungkin dengan lebih sedikit query. Alasannya adalah bahwa satu kueri besar/kompleks lebih hemat biaya dalam hal membangun koneksi database. Keuntungan pengurangan biaya yang mendukung kueri kompleks adalah penggunaan jaringan, pemrosesan/pengoptimalan kueri, dan pemanfaatan sumber daya. Tetapi pendekatan tradisional ini tidak cocok dengan MySQL. MySQL dirancang untuk menangani koneksi dan pemutusan database dengan cepat. Oleh karena itu, membangun koneksi, menjalankan banyak kueri yang lebih sederhana, dan menutup koneksi tampaknya lebih efisien. Mengambil data melalui lebih dari satu kueri sederhana menggantikan satu kueri besar yang kompleks lebih efektif. Perhatikan bahwa ide yang sama mungkin tidak diterapkan dengan database lain.
Kesimpulan
Ini adalah beberapa tip cepat untuk pengoptimalan kueri. Pahami bahwa, mengetahui sintaks SQL, mampu membuat kueri yang mengambil hasil yang diinginkan tidak cukup jika bertujuan untuk kinerja kueri. Memahami kejadian di bawah kueri yang tampak sederhana sangat penting dalam menulis kueri yang tidak hanya mengambil apa yang diinginkan tetapi juga mengilhami seni pengoptimalan sejak semuanya dimulai. Kejadian di balik layar pemrosesan kueri memberikan petunjuk penting untuk memahami kinerja kueri dan pengetahuan ini adalah suatu keharusan sebelum seseorang terjun ke ranah optimasi kueri.
