cara untuk mencegah permintaan menunggu kunci level tabel

Kami mengalami masalah setelah memindahkan basis data pelanggan kami ke server tambahan. Ini seharusnya memiliki efek positif pada kinerja situs, tetapi ada masalah dengan penguncian tabel di MyISAM. (Saya pernah mendengar menggunakan InnoDB bukan MyISAM, tetapi kami tidak dapat mengganti mesin dalam waktu dekat).
Kami dapat menemukannya pada kueri pembaruan yang dilakukan ketika moderator mengaktifkan komentar pada artikel tersebut. Inilah prosesnya:

• pembaruan-permintaan diproses SET status = 1 WHERE id = 5(indeks diatur)
• file halaman yang di-cache dihapus

Pada titik ini seluruh halaman menjadi lambat. Basis data sendiri sibuk selama beberapa menit. Saya mengambil daftar proses beberapa kali dan melihat sekitar 60 entri dari kueri pemilihan yang berbeda, yang semuanya dalam keadaan menunggu kunci tingkat tabel .

1. Saya tidak mengerti mengapa pembaruan ini di atas meja article_commentsdapat memengaruhi pernyataan pilih untuk tabel articleuntuk menunggu kunci level tabel. Dalam daftar proses, hampir semua permintaan menunggu berasal dari tabel ini. Saya telah membaca tentang fakta bahwa pembaruan / sisipan lebih disukai untuk dipilih dan bahwa ini dapat menyebabkan masalah seperti itu, tetapi tabel artikel itu sendiri tidak diperbarui ketika komentar menjadi aktif, sehingga pilihan tidak harus menunggu. Apakah saya salah mengerti?
2. Apakah ada sesuatu selain beralih ke InnoDB untuk mencegah perilaku ini atau setidaknya untuk mendapatkan keseimbangan yang lebih baik? Saya sangat jengkel tentang kenyataan bahwa masalah ini tidak muncul sebelum memindahkan database ke server baru. Saya kira ada beberapa kesalahan konfigurasi tetapi saya tidak tahu cara mengidentifikasi.

MyISAM Storage Engine sangat terkenal karena melakukan kunci tabel penuh untuk setiap DML (INSERT, UPDATE, DELETEs). InnoDB pasti akan mengatasi masalah itu dalam jangka panjang.

Saya menulis tentang pro dan kontra menggunakan MyISAM vs InnoDB

• InnoDB vs MyISAM dengan banyak indeks (05 Jul 2012)
• Mana yang lebih cepat, InnoDB atau MyISAM? (03 Mei 2012)
• Adakah gotcha sama sekali dengan mengkonversi dari MyISAM ke InnoDB? (09 Jan 2012)
• Haruskah saya menggunakan mesin penyimpanan selain MyISAM untuk mengoptimalkan tabel ini atau haruskah saya mendapatkan disk yang lebih baik? (07 Okt 2011)
• Manfaat penguncian tingkat tabel (14 Sep 2011)
• Apa perbedaan utama antara InnoDB dan MyISAM? (14 Apr 2011)

Sehubungan dengan pertanyaan Anda saat ini, berikut adalah skenario yang mungkin:

• articledan article_commentskeduanya adalah tabel MyISAM
• article_commentsmemiliki satu atau lebih indeks dengan statussebagai kolom
• Pembaruan halaman indeks untuk di article_comments-cache dalam Buffer Kunci MyISAM (berukuran oleh key_buffer_size ), menyebabkan halaman indeks lama keluar dari Buffer Kunci MyISAM
• Anda memiliki kueri SELECT yang melakukan GABUNGAN antara articledanarticle_comments

Dalam skenario yang saya sarankan, SELECT terhadap articletabel dapat ditunda untuk mengizinkan penulisan karena harus menunggu untuk article_commentsbebas dari DML apa pun (dalam hal ini, an UPDATE)

Pada titik ini seluruh halaman menjadi lambat. Basis data sendiri sibuk selama beberapa menit.

Baunya seperti kamu punya Query_cache besar?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

Untuk sistem produksi dengan banyak penulisan, Anda juga dapat mematikan MATI query_cache.

Semua entri dalam query_cache untuk tabel yang diberikan dibersihkan ketika setiap penulisan terjadi pada tabel itu. Semakin besar QC, semakin lambat tugas ini.

MyISAM menggunakan kunci "level tabel". Membaca dan menulis tidak dapat terjadi secara bersamaan (di tabel yang sama). Mentah, tetapi efektif.