Lembar Cheat Kinerja MySQL

MySQL sangat luas dan memiliki banyak area untuk dioptimalkan dan diubah untuk kinerja yang diinginkan. Beberapa perubahan dapat dilakukan secara dinamis, yang lain memerlukan restart server. Sangat umum untuk menemukan instalasi MySQL dengan konfigurasi default, meskipun yang terakhir mungkin tidak sesuai dengan beban kerja dan pengaturan Anda.

Berikut adalah area utama di MySQL yang saya ambil dari berbagai sumber ahli di dunia MySQL, serta pengalaman kami sendiri di Somenines. Blog ini akan berfungsi sebagai lembar contekan Anda untuk menyempurnakan kinerja dan menjadikan MySQL Anda hebat lagi :-)

Mari kita lihat ini dengan menguraikan area utama di MySQL.

Variabel Sistem

MySQL memiliki banyak variabel yang dapat Anda pertimbangkan untuk diubah. Beberapa variabel bersifat dinamis yang berarti mereka dapat diatur menggunakan pernyataan SET. Lainnya memerlukan restart server, setelah mereka diatur dalam file konfigurasi (misalnya /etc/my.cnf, etc/mysql/my.cnf). Namun, saya akan membahas hal-hal umum yang cukup umum untuk disetel agar server dioptimalkan.

sort_buffer_size

Variabel ini mengontrol seberapa besar buffer filesort Anda, yang berarti bahwa setiap kali kueri perlu mengurutkan baris, nilai variabel ini digunakan untuk membatasi ukuran yang perlu dialokasikan. Perhatikan bahwa variabel ini adalah basis per-kueri yang diproses (atau per-koneksi), yang berarti akan memakan banyak memori saat Anda menetapkan ini lebih tinggi dan jika Anda memiliki beberapa koneksi yang memerlukan penyortiran baris Anda. Namun, Anda dapat memantau kebutuhan Anda dengan memeriksa variabel status global Sort_merge_passes. Jika nilai ini besar, Anda harus mempertimbangkan untuk meningkatkan nilai variabel sistem sort_buffer_size. Jika tidak, bawa ke batas moderat yang Anda butuhkan. Jika Anda mengatur ini terlalu rendah atau jika Anda memiliki kueri besar untuk diproses, efek pengurutan baris Anda bisa lebih lambat dari yang diharapkan karena data diambil secara acak dengan melakukan disk dives. Hal ini dapat menyebabkan penurunan kinerja. Namun, yang terbaik adalah memperbaiki pertanyaan Anda. Jika tidak, jika aplikasi Anda dirancang untuk menarik kueri besar dan memerlukan penyortiran, maka akan efisien untuk menggunakan alat yang menangani cache kueri seperti Redis. Secara default, di MySQL 8.0, nilai yang ditetapkan saat ini adalah 256 KiB. Setel ini hanya jika Anda memiliki kueri yang banyak menggunakan atau memanggil jenis.

read_buffer_size

Dokumentasi MySQL menyebutkan bahwa untuk setiap permintaan yang melakukan pemindaian tabel secara berurutan, ia mengalokasikan buffer baca. Variabel sistem read_buffer_size menentukan ukuran buffer. Ini juga berguna untuk MyISAM, tetapi variabel ini juga memengaruhi semua mesin penyimpanan. Untuk tabel MEMORY, digunakan untuk menentukan ukuran blok memori.

Pada dasarnya, setiap utas yang melakukan pemindaian berurutan untuk tabel MyISAM mengalokasikan buffer dengan ukuran ini (dalam byte) untuk setiap tabel yang dipindainya. Itu juga berlaku untuk semua mesin penyimpanan (termasuk InnoDB), jadi sangat membantu untuk kueri yang mengurutkan baris menggunakan ORDER BY dan menyimpan indeksnya dalam file sementara. Jika Anda melakukan banyak pemindaian berurutan, menyisipkan secara massal ke tabel partisi, menyimpan hasil kueri bersarang dalam cache, lalu pertimbangkan untuk meningkatkan nilainya. Nilai variabel ini harus kelipatan 4KB. Jika disetel ke nilai yang bukan kelipatan 4KB, nilainya akan dibulatkan ke bawah ke kelipatan 4KB terdekat. Perhatikan bahwa menyetel ini ke nilai yang lebih tinggi akan menghabiskan sebagian besar memori server Anda. Saya menyarankan untuk tidak menggunakan ini tanpa pembandingan dan pemantauan lingkungan Anda yang tepat.

read_rnd_buffer_size

Variabel ini berkaitan dengan membaca baris dari tabel MyISAM dalam urutan yang diurutkan setelah operasi penyortiran kunci, baris dibaca melalui buffer ini untuk menghindari pencarian disk. Dokumentasi mengatakan, ketika membaca baris dalam urutan sewenang-wenang atau dari tabel MyISAM dalam urutan yang diurutkan setelah operasi penyortiran kunci, baris dibaca melalui buffer ini (dan ditentukan melalui ukuran buffer ini) untuk menghindari pencarian disk. Mengatur variabel ke nilai yang besar dapat meningkatkan kinerja ORDER BY cukup banyak. Namun, ini adalah buffer yang dialokasikan untuk setiap klien, jadi Anda tidak boleh menyetel variabel global ke nilai yang besar. Sebagai gantinya, ubah variabel sesi hanya dari dalam klien yang perlu menjalankan kueri besar. Namun, Anda harus mempertimbangkan bahwa ini tidak berlaku untuk MariaDB, terutama saat memanfaatkan MRR. MariaDB menggunakan mrr_buffer_size sedangkan MySQL menggunakan read_buffer_size read_rnd_buffer_size.

join_buffer_size

Secara default, nilainya 256K. Ukuran minimum buffer yang digunakan untuk pemindaian indeks biasa, pemindaian indeks rentang, dan gabungan yang tidak menggunakan indeks dan dengan demikian melakukan pemindaian tabel penuh. Juga digunakan oleh optimasi BKA (yang dinonaktifkan secara default). Tingkatkan nilainya untuk mendapatkan full join yang lebih cepat saat penambahan indeks tidak memungkinkan. Peringatan meskipun mungkin masalah memori jika Anda mengatur ini terlalu tinggi. Ingat bahwa satu buffer gabungan dialokasikan untuk setiap gabungan penuh antara dua tabel. Untuk gabungan kompleks antara beberapa tabel yang indeksnya tidak digunakan, beberapa buffer gabungan mungkin diperlukan. Paling baik dibiarkan rendah secara global dan disetel tinggi dalam sesi (dengan menggunakan sintaks SET SESSION) yang memerlukan gabungan penuh yang besar. Pada platform 64-bit, Windows memotong nilai di atas 4GB menjadi 4GB-1 dengan peringatan.

max_heap_table_size

Ini adalah ukuran maksimum dalam byte untuk tabel MEMORY yang dibuat pengguna yang diizinkan untuk tumbuh. Ini berguna ketika aplikasi Anda berurusan dengan tabel mesin penyimpanan MEMORY. Mengatur variabel saat server aktif tidak berpengaruh pada tabel yang ada kecuali jika dibuat ulang atau diubah. Semakin kecil max_heap_table_size dan tmp_table_size juga membatasi tabel dalam memori internal. Variabel ini juga digabungkan dengan tmp_table_size untuk membatasi ukuran tabel dalam memori internal (ini berbeda dari tabel yang dibuat secara eksplisit sebagai Engine=MEMORY karena hanya berlaku max_heap_table_size), mana yang lebih kecil diterapkan di antara keduanya.

tmp_table_size

Ukuran terbesar untuk tabel sementara di memori (bukan tabel MEMORY) meskipun jika max_heap_table_size lebih kecil, batas bawah akan berlaku. Jika tabel sementara dalam memori melebihi batas, MySQL secara otomatis mengubahnya menjadi tabel sementara di disk. Tingkatkan nilai tmp_table_size (dan max_heap_table_size jika perlu) jika Anda melakukan banyak kueri GROUP BY tingkat lanjut dan Anda memiliki ruang memori besar yang tersedia. Anda dapat membandingkan jumlah tabel sementara internal pada disk yang dibuat dengan jumlah total tabel sementara internal yang dibuat dengan membandingkan nilai variabel Created_tmp_disk_tables dan Created_tmp_tables. Di ClusterControl, Anda dapat memantau ini melalui Dasbor -> grafik Objek Sementara.

table_open_cache

Anda dapat meningkatkan nilai variabel ini jika Anda memiliki banyak tabel yang sering diakses dalam kumpulan data Anda. Ini akan diterapkan untuk semua utas, artinya per basis koneksi. Nilai tersebut menunjukkan jumlah maksimum tabel yang dapat tetap dibuka oleh server di salah satu contoh cache tabel. Meskipun meningkatkan nilai ini meningkatkan jumlah deskriptor file yang dibutuhkan mysqld, jadi sebaiknya Anda mempertimbangkan untuk memeriksa nilai open_files_limit Anda atau memeriksa seberapa besar batas SOFT dan HARD yang ditetapkan di sistem operasi *nix Anda. Anda dapat memantau ini apakah Anda perlu menambah cache tabel dengan memeriksa variabel status Opened_tables. Jika nilai Opened_tables besar dan Anda tidak sering menggunakan FLUSH TABLES (yang hanya memaksa semua tabel untuk ditutup dan dibuka kembali), maka Anda harus meningkatkan nilai variabel table_open_cache. Jika Anda memiliki nilai kecil untuk table_open_cache, dan jumlah tabel yang sering diakses, ini dapat mempengaruhi kinerja server Anda. Jika Anda melihat banyak entri dalam daftar proses MySQL dengan status "Membuka tabel" atau "Menutup tabel", maka inilah saatnya untuk menyesuaikan nilai variabel ini tetapi perhatikan peringatan yang disebutkan sebelumnya. Di ClusterControl, Anda dapat memeriksanya di Dashboards -> Table Open Cache Status atau Dashboards -> Open Tables. Anda dapat memeriksanya di sini untuk info lebih lanjut.

table_open_cache_instances

Menetapkan variabel ini akan membantu meningkatkan skalabilitas, dan tentu saja, kinerja yang akan mengurangi pertengkaran di antara sesi. Nilai yang Anda tetapkan di sini membatasi jumlah instance cache tabel terbuka. Cache tabel terbuka dapat dipartisi menjadi beberapa instance cache yang lebih kecil dengan ukuran table_open_cache / table_open_cache_instances . Sesi hanya perlu mengunci satu instance untuk mengaksesnya untuk pernyataan DML. Ini menyegmentasikan akses cache di antara instance, memungkinkan kinerja yang lebih tinggi untuk operasi yang menggunakan cache ketika ada banyak sesi yang mengakses tabel. (Pernyataan DDL masih memerlukan kunci di seluruh cache, tetapi pernyataan seperti itu jauh lebih jarang daripada pernyataan DML.) Nilai 8 atau 16 direkomendasikan pada sistem yang secara rutin menggunakan 16 inti atau lebih.

tabel_definisi_cache

Definisi tabel cache yaitu di sinilah CREATE TABLE di-cache untuk mempercepat pembukaan tabel dan hanya satu entri per tabel. Akan masuk akal untuk meningkatkan nilainya jika Anda memiliki banyak tabel. Cache definisi tabel membutuhkan lebih sedikit ruang dan tidak menggunakan deskriptor file, tidak seperti cache tabel normal. Peter Zaitsev dari Percona menyarankan jika Anda dapat mencoba pengaturan rumus di bawah ini,

The number of user-defined tables + 10% unless 50K+ tables

Namun perhatikan bahwa nilai default didasarkan pada rumus berikut yang dibatasi hingga batas 2000.

MIN(400 + table_open_cache / 2, 2000)

Jadi jika Anda memiliki jumlah tabel yang lebih besar dibandingkan dengan default, maka masuk akal Anda meningkatkan nilainya. Mempertimbangkan bahwa dengan InnoDB, variabel ini digunakan sebagai batas lunak jumlah instance tabel terbuka untuk cache kamus data. Ini akan menerapkan mekanisme LRU setelah melebihi nilai saat ini dari variabel ini. Batas tersebut membantu mengatasi situasi di mana sejumlah besar memori akan digunakan untuk men-cache instance tabel yang jarang digunakan hingga server berikutnya dimulai ulang. Oleh karena itu, contoh tabel induk dan anak dengan hubungan kunci asing tidak ditempatkan pada daftar LRU dan dapat memaksakan lebih tinggi dari batas yang ditentukan oleh table_definition_cache dan tidak dikenakan penggusuran dalam memori selama LRU. Selain itu, table_definition_cache mendefinisikan batas lunak untuk jumlah tablespace file-per-tabel InnoDB yang dapat dibuka pada satu waktu, yang juga dikendalikan oleh innodb_open_files dan pada kenyataannya, pengaturan tertinggi antara variabel-variabel ini digunakan, jika keduanya disetel . Jika tidak ada variabel yang disetel, table_definition_cache, yang memiliki nilai default lebih tinggi, akan digunakan. Jika jumlah menangani file tablespace terbuka melebihi batas yang ditentukan oleh table_definition_cache atau innodb_open_files, mekanisme LRU mencari daftar file tablespace LRU untuk file yang sepenuhnya memerah dan saat ini tidak sedang diperpanjang. Proses ini dilakukan setiap kali tablespace baru dibuka. Jika tidak ada tablespace "tidak aktif", tidak ada file tablespace yang ditutup. Jadi, ingatlah ini.

max_allowed_packet

Ini adalah ukuran maksimum per koneksi dari kueri atau baris SQL yang dikembalikan. Nilai terakhir meningkat di MySQL 5.6. Namun di MySQL 8.0 (setidaknya pada 8.0.3), nilai default saat ini adalah 64 MiB. Anda mungkin mempertimbangkan untuk menyesuaikan ini jika Anda memiliki baris BLOB besar yang perlu ditarik keluar (atau dibaca), jika tidak, Anda dapat membiarkan pengaturan default ini dengan 8.0 tetapi dalam versi yang lebih lama, defaultnya adalah 4 MiB sehingga Anda dapat menanganinya jika Anda mengalami kesalahan ER_NET_PACKET_TOO_LARGE. Paket terbesar yang dapat ditransmisikan ke atau dari server atau klien MySQL 8.0 adalah 1GB.

koneksi_maks

Ini adalah jumlah koneksi yang diizinkan untuk server MySQL Anda. Jika Anda menemukan kesalahan di MySQL 'Terlalu banyak koneksi', Anda dapat mempertimbangkan untuk mengaturnya lebih tinggi. Secara default, nilai 151 tidak cukup terutama pada basis data produksi, dan mengingat Anda memiliki sumber daya server yang lebih besar (jangan sia-siakan sumber daya server Anda terutama jika itu adalah server MySQL khusus). Namun, Anda harus memiliki deskriptor file yang cukup jika tidak, Anda akan kehabisan. Dalam hal ini, pertimbangkan untuk menyesuaikan batas SOFT dan HARD dari sistem operasi *nix Anda dan tetapkan nilai open_files_limit yang lebih tinggi di MySQL (5000 adalah batas default). Perhatikan bahwa sangat sering aplikasi tidak menutup koneksi ke database dengan benar, dan menyetel max_connections tinggi dapat mengakibatkan beberapa server Anda tidak responsif atau memuat tinggi. Menggunakan kumpulan koneksi di tingkat aplikasi dapat membantu menyelesaikan masalah di sini.

ukuran_cache_utas

Ini adalah cache untuk mencegah pembuatan thread yang berlebihan. Saat klien terputus, utas klien dimasukkan ke dalam cache jika ada kurang dari utas thread_cache_size di sana. Permintaan untuk utas dipenuhi dengan menggunakan kembali utas yang diambil dari cache jika memungkinkan, dan hanya jika cache kosong, utas baru dibuat. Variabel ini dapat ditingkatkan untuk meningkatkan kinerja jika Anda memiliki banyak koneksi baru. Biasanya, ini tidak memberikan peningkatan kinerja yang signifikan jika Anda memiliki implementasi thread yang baik. Namun, jika server Anda melihat ratusan koneksi per detik, Anda biasanya harus mengatur thread_cache_size cukup tinggi sehingga sebagian besar koneksi baru menggunakan utas yang di-cache. Dengan memeriksa perbedaan antara variabel status Connections dan Threads_created, Anda dapat melihat seberapa efisien cache thread. Menggunakan rumus yang dinyatakan dalam dokumentasi, 8 + (max_connections / 100) sudah cukup baik.

query_cache_size

Untuk beberapa pengaturan, variabel ini adalah musuh terburuk mereka. Untuk beberapa sistem yang mengalami beban tinggi dan sibuk dengan pembacaan tinggi, variabel ini akan menghambat Anda. Ada tolok ukur yang telah diuji dengan baik oleh misalnya, Percona. Variabel ini harus disetel ke 0 bersama dengan query_cache_type =0 juga untuk mematikannya. Kabar baiknya di MySQL 8.0 adalah, Tim MySQL telah berhenti mendukung ini, karena variabel ini benar-benar dapat menyebabkan masalah kinerja. Saya harus setuju di blog mereka bahwa tidak mungkin meningkatkan prediktabilitas kinerja. Jika Anda terlibat untuk menggunakan caching kueri, saya sarankan untuk menggunakan Redis atau ProxySQL.

Mesin Penyimpanan - InnoDB

InnoDB adalah mesin penyimpanan yang sesuai dengan ACID dengan berbagai fitur untuk ditawarkan bersama dengan dukungan kunci asing (Integritas Referensial Deklaratif). Ini memiliki banyak hal untuk dikatakan di sini tetapi variabel tertentu yang perlu dipertimbangkan untuk penyetelan:

innodb_buffer_pool_size

Variabel ini bertindak seperti penyangga utama MyISAM tetapi memiliki banyak hal untuk ditawarkan. Karena InnoDB sangat bergantung pada kumpulan buffer, Anda akan mempertimbangkan untuk menyetel nilai ini biasanya ke 70% -80% dari memori server Anda. Juga menguntungkan bahwa Anda memiliki ruang memori yang lebih besar daripada kumpulan data Anda, dan menetapkan nilai yang lebih tinggi untuk kumpulan buffer Anda tetapi tidak terlalu banyak. Di ClusterControl, ini dapat dipantau menggunakan Dashboard -> InnoDB Metrics -> grafik InnoDB Buffer Pool Pages. Anda juga dapat memantau ini dengan SHOW GLOBAL STATUS menggunakan variabel Innodb_buffer_pool_pages*.

innodb_buffer_pool_instances

Untuk beban kerja konkurensi Anda, menyetel variabel ini dapat meningkatkan konkurensi dan mengurangi pertentangan sebagai utas baca/tulis yang berbeda ke halaman yang di-cache. Innodb_buffer_pool_instances minimum harus berada di antara 1 (minimum) &64 (maksimum). Setiap halaman yang disimpan di atau dibaca dari buffer pool ditetapkan ke salah satu instance buffer pool secara acak, menggunakan fungsi hashing. Setiap kumpulan buffer mengelola daftar gratisnya sendiri, daftar flush, LRU, dan semua struktur data lainnya yang terhubung ke kumpulan buffer, dan dilindungi oleh mutex kumpulan buffernya sendiri. Perhatikan bahwa opsi ini hanya berlaku ketika innodb_buffer_pool_size>=1GiB dan ukurannya dibagi di antara instance kumpulan buffer.

innodb_log_file_size

Variabel ini adalah file log dalam grup log. Ukuran gabungan file log (innodb_log_file_size * innodb_log_files_in_group) tidak boleh melebihi nilai maksimum yang sedikit kurang dari 512GB. Menurut Vadim, ukuran file log yang lebih besar lebih baik untuk kinerja, tetapi memiliki kelemahan (yang signifikan) yang perlu Anda khawatirkan:waktu pemulihan setelah crash. Anda perlu menyeimbangkan waktu pemulihan jika terjadi pemulihan kerusakan yang jarang terjadi versus memaksimalkan throughput selama operasi puncak. Batasan ini dapat menyebabkan proses pemulihan kerusakan 20x lebih lama!

Untuk menguraikannya, nilai yang lebih besar akan baik untuk log transaksi InnoDB dan sangat penting untuk kinerja penulisan yang baik dan stabil. Semakin besar nilainya, semakin sedikit aktivitas flush pos pemeriksaan yang diperlukan di kumpulan buffer, sehingga menghemat I/O disk. Namun, proses pemulihan cukup lambat setelah basis data Anda dimatikan secara tidak normal (rusak atau mati, baik OOM atau tidak disengaja). Idealnya, Anda dapat memiliki 1-2GiB dalam produksi tetapi tentu saja Anda dapat menyesuaikan ini. Membandingkan perubahan ini dapat menjadi keuntungan besar untuk melihat bagaimana kinerjanya terutama selama setelah crash.

innodb_log_buffer_size

Untuk menyimpan I/O disk, InnoDB's menulis data perubahan ke buffer log lt dan menggunakan nilai innodb_log_buffer_size yang memiliki nilai default 8MiB. Ini bermanfaat terutama untuk transaksi besar karena tidak perlu menulis log perubahan ke disk sebelum melakukan transaksi. Jika lalu lintas tulis Anda terlalu tinggi (menyisipkan, menghapus, memperbarui), membuat buffer lebih besar akan menghemat I/O disk.

innodb_flush_log_at_trx_commit

Ketika innodb_flush_log_at_trx_commit disetel ke 1, buffer log dihapus pada setiap transaksi yang dikomit ke file log pada disk dan memberikan integritas data maksimum tetapi juga memiliki dampak kinerja. Menyetelnya ke 2 berarti buffer log di-flush ke cache file OS pada setiap komit transaksi. Implikasi dari 2 adalah optimal dan meningkatkan kinerja jika Anda dapat melonggarkan persyaratan ACID Anda, dan dapat menanggung kerugian transaksi selama satu atau dua detik terakhir jika OS mogok.

innodb_thread_concurrency

Dengan penyempurnaan mesin InnoDB, disarankan untuk mengizinkan mesin mengontrol konkurensi dengan mempertahankannya ke nilai default (yaitu nol). Jika Anda melihat masalah konkurensi, Anda dapat menyetel variabel ini. Nilai yang disarankan adalah 2 kali jumlah CPU ditambah jumlah disk. Variabel dinamisnya berarti dapat diatur tanpa me-restart server MySQL.

innodb_flush_method

Variabel ini harus dicoba dan diuji pada perangkat keras mana yang paling cocok untuk Anda. Jika Anda menggunakan RAID dengan cache yang didukung baterai, DIRECT_IO membantu meringankan tekanan I/O. I/O langsung tidak di-cache sehingga menghindari buffering ganda dengan kumpulan buffer dan cache sistem file. Jika disk Anda disimpan di SAN, O_DSYNC mungkin lebih cepat untuk beban kerja baca-berat dengan sebagian besar pernyataan SELECT.

innodb_file_per_table

innodb_file_per_table AKTIF secara default dari MySQL 5.6. Ini biasanya direkomendasikan karena menghindari memiliki tablespace bersama yang besar dan karena memungkinkan Anda untuk mendapatkan kembali ruang ketika Anda menjatuhkan atau memotong tabel. Tablespace terpisah juga bermanfaat untuk skema pencadangan parsial Xtrabackup.

innodb_stats_on_metadata

Ini mencoba untuk menjaga persentase halaman kotor di bawah kontrol, dan sebelum plugin Innodb, ini benar-benar satu-satunya cara untuk menyetel pembilasan buffer kotor. Namun, saya telah melihat server dengan buffer kotor 3% dan mereka mencapai usia pos pemeriksaan maksimal. Cara ini meningkatkan pembilasan buffer kotor juga tidak menskalakan dengan baik pada subsistem io tinggi, ini secara efektif hanya menggandakan pembilasan buffer kotor per detik ketika % halaman kotor melebihi jumlah ini.

innodb_io_capacity

Pengaturan ini, terlepas dari semua harapan besar kami bahwa itu akan memungkinkan Innodb untuk menggunakan IO kami dengan lebih baik di semua operasi, cukup mengontrol jumlah pembilasan halaman kotor per detik (dan tugas latar belakang lainnya seperti baca-depan). Buat ini lebih besar, Anda menyiram lebih banyak per detik. Ini tidak beradaptasi, itu hanya melakukan banyak iops setiap detik jika ada buffer kotor untuk disiram. Ini akan secara efektif menghilangkan pengoptimalan konsolidasi IO apa pun jika Anda memiliki beban kerja tulis yang cukup rendah (yaitu, halaman kotor segera dihapus, kami mungkin lebih baik tanpa log transaksi dalam kasus ini). Itu juga dapat dengan cepat membuat data yang dibaca dan ditulis ke log transaksi kelaparan jika Anda menyetelnya terlalu tinggi.

innodb_write_io_threads

Mengontrol berapa banyak utas yang akan ditulis dalam proses ke disk. Saya tidak yakin mengapa ini masih berguna jika Anda dapat menggunakan AIO asli Linux. Ini juga dapat dianggap tidak berguna oleh sistem file yang tidak mengizinkan penulisan paralel ke file yang sama oleh lebih dari satu utas (terutama jika Anda memiliki tabel yang relatif sedikit dan/atau menggunakan ruang tabel global)

innodb_adaptive_flushing

Menentukan apakah akan secara dinamis menyesuaikan tingkat pembilasan halaman kotor di kumpulan buffer InnoDB berdasarkan beban kerja. Menyesuaikan laju flush secara dinamis dimaksudkan untuk menghindari ledakan aktivitas I/O. Biasanya, ini diaktifkan secara default . Variabel ini, jika diaktifkan, mencoba untuk lebih pintar membilas lebih agresif berdasarkan jumlah halaman kotor dan tingkat pertumbuhan log transaksi.

innodb_dedicated_server

Variabel ini baru di MySQL 8.0 yang diterapkan secara global dan memerlukan restart MySQL karena ini bukan variabel dinamis. Namun, sebagai dokumentasi menyatakan bahwa variabel ini diinginkan untuk diaktifkan hanya jika MySQL Anda berjalan pada server khusus. Jika tidak, jangan aktifkan ini pada host bersama atau berbagi sumber daya sistem dengan aplikasi lain. Ketika ini diaktifkan, InnoDB akan melakukan konfigurasi otomatis untuk jumlah memori yang terdeteksi untuk variabel innodb_buffer_pool_size, innodb_log_file_size, innodb_flush_method. Satu-satunya downside adalah bahwa Anda tidak dapat memiliki kelayakan untuk menerapkan nilai yang Anda inginkan pada variabel terdeteksi yang disebutkan.

MyISAM

key_buffer_size

InnoDB adalah mesin penyimpanan default MySQL sekarang, default untuk key_buffer_size mungkin dapat dikurangi kecuali Anda menggunakan MyISAM secara produktif sebagai bagian dari aplikasi Anda (tetapi siapa yang menggunakan MyISAM dalam produksi sekarang?). Saya menyarankan di sini untuk menetapkan mungkin 1% dari RAM atau 256 MiB di awal jika Anda memiliki memori yang lebih besar dan mendedikasikan sisa memori untuk cache OS dan kumpulan buffer InnoDB Anda.

Ketentuan Lain Untuk Performa

slow_query_log

Tentu saja, variabel ini tidak membantu meningkatkan server MySQL Anda. Namun, variabel ini dapat membantu Anda menganalisis kueri berperforma lambat. Nilai dapat diatur ke 0 atau OFF untuk menonaktifkan logging. Mengaturnya ke 1 atau ON untuk mengaktifkan ini. Nilai default tergantung pada apakah opsi --slow_query_log diberikan. Tujuan untuk keluaran log dikendalikan oleh variabel sistem log_output; jika nilai tersebut NONE, tidak ada entri log yang ditulis meskipun log diaktifkan. Anda dapat menyetel nama file atau tujuan file log kueri dengan menyetel variabel slow_query_log_file.

waktu_kueri_panjang

Jika kueri membutuhkan waktu lebih lama dari beberapa detik ini, server menambahkan variabel status Slow_queries. Jika log kueri lambat diaktifkan, kueri akan dicatat ke file log kueri lambat. Nilai ini diukur secara real time, bukan waktu CPU, jadi kueri yang berada di bawah ambang batas pada sistem yang dimuat ringan mungkin berada di atas ambang batas pada yang banyak dimuat. Nilai minimum dan default long_query_time adalah 0 dan 10, masing-masing. Perhatikan juga bahwa jika variabel min_examined_row_limit disetel> 0, itu tidak akan mencatat kueri meskipun terlalu lama jika jumlah baris yang dikembalikan kurang dari nilai yang ditetapkan dalam min_examined_row_limit.

Untuk info lebih lanjut tentang menyetel pencatatan log kueri yang lambat, periksa dokumentasi di sini.

sync_binlog

Variabel ini mengontrol seberapa sering MySQL akan menyinkronkan binlog ke disk. Secara default (>=5.7.7), ini disetel ke 1 yang berarti akan disinkronkan ke disk sebelum transaksi dilakukan. Namun, ini memberikan dampak negatif pada kinerja karena peningkatan jumlah penulisan. Tapi ini adalah pengaturan teraman jika Anda ingin benar-benar mematuhi ACID bersama dengan budak Anda. Atau, Anda dapat mengatur ini ke 0 jika Anda ingin menonaktifkan sinkronisasi disk dan hanya mengandalkan OS untuk menghapus log biner ke disk dari waktu ke waktu. Menyetelnya lebih tinggi dari 1 berarti binlog disinkronkan ke disk setelah N grup komit log biner dikumpulkan, di mana N adalah> 1.

Buang/Kembalikan Buffer Pool

Adalah hal yang cukup umum bahwa basis data produksi Anda perlu melakukan pemanasan dari start/restart yang dingin. Dengan membuang kumpulan buffer saat ini sebelum memulai ulang, itu akan menyimpan konten dari kumpulan buffer dan setelah selesai, itu akan memuat konten kembali ke kumpulan buffer.. Dengan demikian, ini menghindari kebutuhan untuk menghangatkan database Anda kembali ke cache. Perhatikan bahwa, versi ini sejak diperkenalkan pada 5.6 tetapi Percona Server 5.5 sudah tersedia, kalau-kalau Anda bertanya-tanya. Untuk mengaktifkan fitur ini, setel kedua variabel innodb_buffer_pool_dump_at_shutdown =ON dan innodb_buffer_pool_load_at_startup =ON.

Perangkat Keras

Kami sekarang di 2019, ada banyak peningkatan perangkat keras baru. Biasanya, tidak ada persyaratan keras bahwa MySQL akan memerlukan perangkat keras tertentu, tetapi ini tergantung pada apa yang Anda perlukan untuk dilakukan database. Saya berharap Anda tidak membaca blog ini karena Anda sedang menguji apakah itu berjalan pada Intel Pentium 200 MHz.

Untuk CPU, prosesor yang lebih cepat dengan banyak inti akan optimal untuk MySQL di versi terbaru setidaknya sejak 5.6. Prosesor Intel Xeon/Itanium bisa mahal tetapi diuji untuk platform komputasi yang skalabel dan andal. Amazon telah mengirimkan instans EC2 mereka yang berjalan pada arsitektur ARM. Meskipun saya pribadi belum pernah mencoba menjalankan atau mengingat menjalankan MySQL pada arsitektur ARM, ada tolok ukur yang telah dibuat bertahun-tahun yang lalu. CPU modern dapat meningkatkan dan menurunkan frekuensinya berdasarkan suhu, beban, dan kebijakan penghematan daya OS. Namun, ada kemungkinan pengaturan CPU Anda di OS Linux Anda diatur ke gubernur yang berbeda. Anda dapat memeriksanya atau menyetelnya dengan gubernur “kinerja” dengan melakukan hal berikut:

echo performance | sudo tee /sys/devices/system/cpu/cpu[0-9]*/cpufreq/scaling_governor

Untuk Memori, sangat penting bahwa memori Anda besar dan dapat menyamakan ukuran dataset Anda. Pastikan Anda memiliki swappiness =1. Anda dapat memeriksanya dengan memeriksa sysctl atau memeriksa file di procfs. Ini dicapai dengan melakukan hal berikut:

$ sysctl -e vm.swappiness
vm.swappiness = 1

Atau set ke nilai 1 sebagai berikut

$ sudo sysctl vm.swappiness=1
vm.swappiness = 1

Hal hebat lainnya yang perlu dipertimbangkan untuk manajemen Memori Anda adalah mempertimbangkan untuk mematikan THP (Halaman Besar Transparan). Di masa lalu, saya ingat kami memiliki beberapa masalah aneh yang dihadapi dengan pemanfaatan CPU dan mengira itu karena I/O disk. Ternyata, masalahnya adalah dengan utas kernel khugepaged yang mengalokasikan memori secara dinamis selama runtime. Tidak hanya itu, selama kernel melakukan defragmentasi, memori Anda akan dialokasikan dengan cepat saat melewatinya ke THP. Memori HugePages standar telah dialokasikan sebelumnya saat startup, dan tidak berubah selama runtime. Anda dapat memverifikasi dan menonaktifkan ini dengan melakukan hal berikut:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ echo "never" > /sys/kernel/mm/transparent_hugepage/enabled

Untuk Disk, penting bahwa Anda memiliki throughput yang baik. Menggunakan RAID10 adalah pengaturan terbaik untuk database dengan unit cadangan baterai. Dengan munculnya flash drive yang menawarkan throughput disk tinggi dan I/O disk tinggi untuk baca/tulis, penting agar flash drive dapat mengelola penggunaan disk dan I/O disk yang tinggi.

Sistem Operasi

Sebagian besar sistem produksi yang berjalan di MySQL berjalan di Linux. Itu karena MySQL telah diuji dan di-benchmark di Linux, dan terdengar bahwa itu adalah standar de facto untuk instalasi MySQL. Namun, tentu saja, tidak ada yang menghentikan Anda untuk menggunakannya di platform Unix atau Windows. Akan lebih mudah jika platform Anda telah diuji dan ada komunitas luas untuk membantu, jika Anda mengalami masalah. Kebanyakan setup berjalan pada sistem RHEL/Centos/Fedora dan Debian/Ubuntu. Di AWS, Amazon memiliki Amazon Linux yang saya lihat juga digunakan dalam produksi oleh beberapa orang.

Yang paling penting untuk dipertimbangkan dengan pengaturan Anda adalah bahwa sistem file Anda menggunakan XFS atau Ext4. Yang pasti, ada pro dan kontra antara kedua sistem file ini, tetapi saya tidak akan membahas detailnya di sini. Ada yang mengatakan XFS mengungguli Ext4 tetapi ada laporan juga bahwa Ext4 mengungguli XFS. ZFS juga muncul sebagai kandidat yang baik untuk sistem file alternatif. Jervin Real (dari Percona) memiliki sumber yang bagus untuk yang satu ini, Anda dapat memeriksa presentasi ini selama konferensi ZFS.

Tautan Eksternal

https://developer.okta.com/blog/2015/05/22/tcmalloc

https://www.percona.com/blog/2012/07/05/impact-of-memory-allocators-on-mysql-performance/

https://www.percona.com/live/18/sessions/benchmark-noise-reduction-how-to-configure-your-machines-for-stable-results

https://zfs.datto.com/2018_slides/real.pdf

https://docs.Oracle.com/en/database/Oracle/Oracle-database/12.2/ladbi/disabling-transparent-hugepages.html#GUID-02E9147D-D565-4AF8-B12A-8E6E9F74BEEA