Mengira Query Cache Masih Ada Saat Upgrade Database ke MySQL 8.0

Setelah upgrade basis data dari MySQL 5.7 ke MySQL 8.0, tidak sedikit pengelola server mendapati penggunaan CPU tiba-tiba melonjak tinggi padahal volume trafik website relatif sama. Salah satu pemicu yang sering terlewat adalah hilangnya Query Cache secara menyeluruh di versi 8.0. Mekanisme lama yang selama ini menyembunyikan query lambat atau query berulang sudah tidak ada lagi di dalam mesin MySQL. Di meja bantuan teknis, kasus semacam ini sering memicu kebingungan karena konfigurasi lama di berkas my.cnf masih tampak terpasang rapi tanpa memunculkan error fatal saat daemon dinyalakan. Untuk memahami apa yang sebenarnya terjadi pada infrastruktur kamu, mari kita bedah beberapa miskonsepsi umum seputar Query Cache di MySQL 8.0.

Mitos 1: Pengaturan query_cache_size di my.cnf Masih Berfungsi

Banyak orang mengira selama baris query_cache_type = 1 dan query_cache_size = 64M masih tertulis di file konfigurasi, MySQL akan tetap menyimpan hasil SELECT di memori. Anggapan ini terasa masuk akal karena server tetap berjalan normal setelah restart dan tidak langsung mengalami crash. Kenyataannya, MySQL 8.0 menghapus seluruh subsistem Query Cache dari kode sumbernya. Variabel sistem terkait Query Cache tidak lagi dikenali. Jika kamu menuliskan opsi ini di versi 8.0 awal, MySQL bahkan bisa menolak menyala jika opsi dianggap usang (unknown variable). Pada beberapa distribusi atau skenario upgrade tertentu, opsi ini diabaikan begitu saja tanpa efek apa pun. Hasilnya, nol bita memori dialokasikan untuk Query Cache, dan tidak ada satu pun hasil query yang ditampung secara otomatis oleh database. Kamu bisa memverifikasi langsung lewat MySQL client apakah variabel tersebut masih ada atau sudah benar-benar hilang:

BASH

mysql -u root -p -e "SHOW VARIABLES LIKE 'have_query_cache'; SHOW VARIABLES LIKE 'query_cache_%';"

Pada MySQL 8.0, perintah tersebut akan menghasilkan tabel kosong. Tidak ada lagi mekanisme Query Cache bawaan di dalam server engine.

Mitos 2: Query Cache Dihapus Hanya Karena Kurang Populer

Ada anggapan bahwa fitur ini dihentikan hanya karena pengembang MySQL ingin menyederhanakan kode produk tanpa alasan teknis mendesak. Pengelola server yang terbiasa melihat hit rate tinggi di era MySQL 5.5 atau 5.6 sering merasa fitur ini sangat menguntungkan. Kenyataannya, Query Cache memiliki kelemahan arsitektural yang parah pada perangkat keras modern dengan banyak core CPU. Query Cache bekerja dengan mengunci mutex global tunggal setiap kali ada query yang dibaca atau disimpan. Ketika ada tabel yang menerima operasi tulis (INSERT, UPDATE, atau DELETE), seluruh cache yang berelasi dengan tabel tersebut harus dibersihkan (invalidation) secara menyeluruh. Pada server dengan konkurensi tinggi, perebutan lock pada Query Cache justru menjadi leher botol (bottleneck) utama. Core CPU yang banyak malah terkunci saling menunggu giliran untuk mengakses cache yang sama. Alih-alih mempercepat, Query Cache lawas justru membatasi throughput sistem pada aplikasi web dinamis yang sering melakukan pembaruan data.

Mitos 3: InnoDB Buffer Pool Otomatis Menggantikan Fungsi Query Cache

Miskonsepsi lain yang sering terdengar adalah anggapan bahwa InnoDB Buffer Pool berfungsi sebagai pengganti langsung Query Cache. Karena sama-sama menyimpan data di RAM, sebagian admin beranggapan alokasi memori untuk database otomatis menangani hal yang sama. Kenyataannya, kedua komponen ini bekerja pada lapisan yang sangat berbeda. Query Cache menyimpan teks query utuh beserta set hasil akhirnya (result set). Ketika ada query yang persis sama masuk, MySQL langsung mengembalikan hasil tanpa perlu membedah sintaks, mengecek permission tabel, atau menjalankan optimasi eksekusi. Sebaliknya, InnoDB Buffer Pool menyimpan halaman data mentah dan indeks (data pages) dari disk ke memori. Database tetap harus mem-parse query, menyusun execution plan, membaca baris-baris data dari halaman memori, dan mengolah hasilnya sebelum dikirim ke klien. Menyesuaikan memori lewat panduan Cara Memastikan Ukuran InnoDB Buffer Pool di Server Sudah Pas memang sangat penting untuk menekan I/O disk, tetapi CPU tetap harus bekerja memproses komputasi query tersebut setiap kali dipanggil.

Mitos 4: Database Harus Menyelesaikan Semua Urusan Caching Sendiri

Banyak praktisi infrastruktur masih berharap basis data relasional mampu menangani caching hasil kalkulasi tinggi secara mandiri tanpa bantuan layer lain. Pola pikir ini membuat tim terus mencari parameter tersembunyi di database untuk meredam lonjakan beban CPU pasca-upgrade. Kenyataannya, standar industri modern memindahkan tanggung jawab caching hasil komputasi ke level aplikasi atau menggunakan in-memory key-value store khusus seperti Redis atau Memcached. Pendekatan ini jauh lebih aman dan skalabel karena:

Cache invalidation dapat dikontrol secara granular oleh logika aplikasi, bukan secara kasar menghapus seluruh cache tabel.
Beban parsing query, koneksi jaringan, dan pemrosesan data sama sekali tidak menyentuh database relasional.
Throughput pembacaan data cache bisa dinaikkan secara independen tanpa membebani thread kerja MySQL.

Ketika server database kamu mengalami kenaikan beban kerja setelah beralih ke MySQL 8.0, jangan habiskan waktu mencari cara menghidupkan kembali Query Cache bawaan. Fokuslah pada dua langkah nyata: periksa query lambat menggunakan slow query log untuk memastikan indeks tabel sudah optimal, lalu terapkan object caching di lapisan aplikasi untuk data yang frekuensi bacanya jauh lebih tinggi daripada frekuensi tulisnya.