Halo teman-teman saya akan melanjutkan pembahasan tentang Penyesuaian Kinerja MySQL Yang Perlu Diperhatikan. Innodb_flush_log_at_trx_commit adalah tentang Innodb yang 100 kali lebih lambat dari MyISAM? Teman-teman mungkin lupa menyesuaikan nilai ini. Nilai default dari 1 akan berarti setiap transaksi pembaruan komit (atau setiap pernyataan di luar transaksi) perlu memasukkan log ke disk yang agak mahal, terutama jika Teman-teman tidak memiliki cadangan cadangan baterai. Banyak aplikasi, terutama yang bergerak dari tabel MyISAM tidak masalah dengan nilai 2 yang berarti tidak menyiram log ke disk tapi hanya menyiramnya ke cache OS. Log masih memerah ke disk setiap detik sehingga Teman-teman biasanya tidak akan kehilangan lebih dari 1-2 sec layak update. Nilai 0 sedikit lebih cepat namun sedikit kurang aman karena Teman-teman dapat kehilangan transaksi meskipun MySQL Server mengalami crash. Nilai 2 hanya menyebabkan kehilangan data dengan full OS crash.

Table_cache – Pembukaan meja bisa mahal. Sebagai contoh, tabel MyISAM menTeman-temani MYI header untuk menTeman-temani tabel sebagai sedang digunakan. Teman-teman tidak ingin hal ini terjadi begitu sering dan biasanya paling baik untuk ukuran cache Teman-teman sehingga cukup besar untuk menjaga sebagian besar tabel Teman-teman terbuka. Ini menggunakan beberapa sumber daya OS dan beberapa memori tapi untuk perangkat keras modern, biasanya tidak masalah. 1024 adalah nilai bagus untuk aplikasi dengan beberapa ratus tabel (ingat setiap koneksi memerlukan entri sendiri) jika Teman-teman memiliki banyak koneksi atau banyak tabel akan bertambah lebih besar. Saya telah melihat nilai lebih dari 100.000 digunakan.

Thread_cache Pembuatan / penghancuran thread bisa mahal, yang terjadi pada masing-masing connect / disconnect. Saya biasanya menetapkan nilai ini setidaknya 16. Jika aplikasi memiliki lompatan besar dalam jumlah koneksi konkuren dan saya akan melihat pertumbuhan yang cepat

Variabel Threads_Created saya mendongkraknya lebih tinggi. Tujuannya bukan untuk memiliki benang yang dibuat dalam operasi normal.

Query_cache_size jika aplikasi Teman-teman dibaca intensif dan Teman-teman tidak memiliki cache tingkat aplikasi, ini bisa sangat membantu. Jangan meletakkannya terlalu besar karena bisa memperlambat segalanya karena perawatannya mungkin akan mahal. Nilai dari 32M ke 512M biasanya masuk akal. Periksa saja setelah beberapa saat dan lihat apakah sudah terbiasa. Untuk beban kerja tertentu, rasio hit tembus lebih rendah daripada yang seharusnya dibenarkan jika mengaktifkannya.

Catatan: karena Teman-teman bisa melihat semua ini adalah variabel global. Variabel ini bergantung pada perangkat keras dan campuran mesin penyimpanan, sedangkan per variabel sesi biasanya memuat beban kerja. Jika Teman-teman memiliki pertanyaan sederhana, tidak ada alasan untuk meningkatkan sort_buffer_size bahkan jika Teman-teman memiliki memori 64GB untuk dibuang. Selanjutnya hal tersebut dapat menurunkan kinerja.

Saya biasanya meninggalkan tuning variabel per sesi ke langkah kedua setelah saya dapat menganalisis beban kerja.

P.S Catatan Distribusi MySQL berisi sekumpulan file my.cnf contoh yang mungkin merupakan templat hebat yang akan digunakan untuk penyetelan kinerja database MySQL Teman-teman. Biasanya mereka sudah jauh lebih baik daripada default jika Teman-teman memilih yang benar. Semoga bermanfaat