Anda harus menonaktifkan cache permintaan dengan
[mysqld]
query_cache_size = 0
dan kemudian restart mysql. Mengapa saya menyarankan itu ???
Cache Kueri akan selalu berbenturan dengan InnoDB. Alangkah baiknya jika MVCC InnoDB akan membiarkan kueri dilayani dari cache kueri jika modifikasi tidak memengaruhi pembacaan berulang untuk transaksi lainnya. Sayangnya, InnoDB tidak melakukan itu. Rupanya, Anda memiliki banyak pertanyaan yang dibatalkan agak cepat dan mungkin tidak digunakan kembali.
Untuk InnoDB di bawah MySQL 4.0, cache kueri dinonaktifkan untuk transaksi. Untuk MySQL 4.1+, InnoDB memainkan polisi lalu lintas ketika mengizinkan akses ke cache kueri berdasarkan tabel.
Dari sudut pandang pertanyaan Anda, saya akan mengatakan bahwa pembenaran untuk menghapus cache kueri tidak terlalu mahal, tetapi bagaimana InnoDB mengelolanya.
Untuk informasi lebih lanjut tentang bagaimana InnoDB berinteraksi dengan cache kueri, silakan baca halaman 213-215 dari buku "MySQL Kinerja Tinggi (Edisi Kedua)" .
Jika semua atau sebagian besar data Anda adalah MyISAM, Anda bisa menggunakan ide awal Anda menggunakan SQL_NO_CACHE.
Jika Anda memiliki campuran InnoDB dan MyISAM, Anda harus menemukan keseimbangan yang tepat untuk aplikasi Anda berdasarkan pada seberapa tinggi kesalahan cache Anda. Bahkan, halaman 209-210 dari buku yang sama menunjukkan alasan untuk melewatkan cache:
- Kueri ini tidak dapat di-cache, baik karena mengandung konstruk nondeterministik (seperti CURRENT_DATE) atau karena set hasilnya terlalu besar untuk disimpan. Kedua jenis kueri yang tidak dapat disimpan menambah variabel status Qcache_not_cached.
- Server belum pernah melihat kueri sebelumnya, sehingga tidak pernah memiliki kesempatan untuk men-cache hasilnya.
- Hasil kueri sebelumnya di-cache, tetapi server menghapusnya. Ini dapat terjadi karena tidak ada cukup memori untuk menyimpannya, karena seseorang menginstruksikan server untuk menghapusnya, atau karena itu tidak valid
dan akar penyebab kesalahan cache tinggi dengan beberapa kueri yang tidak bisa disimpan adalah:
- Cache permintaan belum hangat. Itu adalah server tidak memiliki kesempatan untuk mengisi cache dengan set hasil.
- Server melihat kueri yang belum pernah dilihat sebelumnya. Jika Anda tidak memiliki banyak kueri berulang, ini bisa terjadi bahkan setelah cache dipanaskan.
- Ada banyak cacat cache.
UPDATE 2012-09-06 10:10 EDT
Melihat info terbaru Anda, Anda telah query_cache_limitmengatur ke 1048576 (1M). Ini membatasi hasil apa pun yang ditetapkan ke 1 jt. Jika Anda mengambil sesuatu yang lebih besar, itu tidak akan di-cache. Meskipun Anda telah query_cache_sizemenetapkan untuk 104857600 (100M), ini hanya memungkinkan untuk 100 hasil yang di-cache ditetapkan di dunia yang sempurna. Jika Anda melakukan ratusan pertanyaan, fragmentasi akan terjadi lebih cepat. Anda juga memiliki 4096 (4K) sebagai hasil ukuran minimum yang ditetapkan. Sayangnya, mysql tidak memiliki mekanisme internal untuk defragmenting cache permintaan.
Jika Anda harus memiliki cache kueri dan Anda memiliki begitu banyak RAM, Anda dapat menjalankan yang berikut:
SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;
untuk membersihkan cache kueri. Anda kehilangan semua hasil dalam tembolok, jadi jalankan baris ini selama jam sibuk.
Saya juga akan menetapkan yang berikut:
- query_cache_size = 1G
- query_cache_limit = 8M
Itu menyisakan 23G RAM. Saya akan mengajukan yang berikut:
- innodb_buffer_pool_size = 12G
- key_buffer_size = 4G
Itu menyisakan 7G. Ini harus memadai untuk Koneksi OS dan DB.
Perlu diingat bahwa buffer kunci hanya menyimpan cache halaman indeks MyISAM, sedangkan Pool Penyangga InnoDB menyimpan data dan indeks.
Satu rekomendasi lagi: tingkatkan ke MySQL 5.5 sehingga Anda dapat mengonfigurasi InnoDB untuk banyak CPU dan beberapa utas untuk baca / tulis I / O.
Lihat posting saya sebelumnya tentang penggunaan MySQL 5.5 bersamaan dengan mengakses beberapa CPU untuk InnoDB
UPDATE 2012-09-06 14:56 EDT
Metode saya untuk membersihkan cache permintaan agak ekstrem karena menyemprotkan data yang di-cache dan membentuk segmen RAM yang sama sekali berbeda. Seperti yang Anda tunjukkan dalam komentar Anda, FLUSH QUERY CACHE(seperti yang Anda sarankan) atau bahkan RESET QUERY CACHEakan lebih baik. Untuk klarifikasi, ketika saya mengatakan "tidak ada mekanisme internal," saya maksudkan itu. Defragmentasi diperlukan dan harus dilakukan secara manual. Itu harus crontab'd .
Jika Anda melakukan DML (INSERT, UPDATE, DELETEs) di InnoDB lebih sering daripada di MyISAM, saya akan mengatakan hapus cache permintaan sama sekali, yang saya katakan di awal.