Slow Query Log WordPress: long_query_time, pt-query-digest, dan Cara Membaca Query Pembunuh Server

Query Monitor tampil hijau di layar admin, tetapi website tetap lambat setiap jam ramai dan tidak ada fatal error sama sekali. Waktu tunggu database tidak dihitung max_execution_time, seperti dibedah di artikel Max Execution Time WordPress, sehingga kecurigaan beralih ke query yang tak terlihat dari dashboard. Inilah momen slow query log wordpress bekerja: ia mencatat query lambat di level server, termasuk WP-Cron malam hari dan request lintas situs. Panduan ini membahas tiga lapis alat diagnosis, parameter aktivasi, dan cara membaca log sampai keputusan perbaikan.

Apa Itu Slow Query Log dan Kenapa WordPress Membutuhkannya?

Slow query log adalah fitur bawaan MySQL dan MariaDB yang mencatat setiap query melewati ambang waktu ke file log. Query dicatat bukan karena gagal, melainkan karena lambat. File ini hidup di disk dan terus bertambah selama logging aktif: rekam jejak historis, bukan potret sesaat satu request.

Mayoritas waktu tunggu request dinamis WordPress habis di database: arsip, pencarian, dan checkout mengeksekusi puluhan query sebelum PHP merender HTML. Gejalanya tak terlihat dari PHP karena penantian terjadi di storage engine. Di sinilah observability database bermula: melihat kerja database berdasar bukti, bukan tebakan.

Posisinya dalam klaster adalah diagnosis penghubung antara artikel gejala dan artikel solusi: artikel ini menjawab query mana yang sebenarnya lambat di server saya.

Tiga Lapis Alat Diagnosis Query: SAVEQUERIES, Query Monitor, dan Log Server

Tiga lapis alat diagnosis query WordPress sering dicampuradukkan, padahal cakupannya berbeda. SAVEQUERIES adalah konstanta wp-config.php yang mencatat semua query satu request di memori untuk sesi dev singkat. Query Monitor adalah plugin analisis per request di admin UI, tetapi butuh login admin dan buta terhadap koneksi non-WordPress.

Slow query log server lintas request dan lintas situs, persisten di disk, dan meliputi semua koneksi ke MariaDB: WP-Cron malam hari, import via CLI, dan tool eksternal. Detail cron tersembunyi ada di artikel Disable WP-Cron. Diagram berikut memetakan ketiga lapis dan blind spot masing-masing.

Parameter Kunci: slow_query_log, long_query_time, dan log_queries_not_using_indexes

Pembahasan mariadb slow query log kembali ke empat parameter penentu kualitas data. slow_query_log menghidupkan pencatatan, slow_query_log_file menentukan lokasi file yang wajib dipasangi rotasi log agar disk aman.

long_query_time adalah ambang detik penentu query tercatat. Default resmi 10 detik terlalu tinggi untuk WordPress; titik mulai wajar produksi adalah 1 sampai 2 detik. Nilai 0 mencatat semua query dan hanya untuk sesi singkat di staging. Istilah threshold berarti garis batas waktu.

log_queries_not_using_indexes mencatat query tanpa indeks meski di bawah ambang, relevan untuk WordPress tetapi bisa berisik. Dua jalur berlaku: SET GLOBAL untuk runtime yang hilang saat restart, dan my.cnf untuk persisten:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

Restart MariaDB di jam sepi, lalu verifikasi dengan SHOW VARIABLES LIKE 'slow_query_log%'; sebelum pengumpulan data dimulai.

Kapan Harus Curigai Query Database? Membaca Gejala Sebelum Membaca Log

Penanda klasiknya: TTFB tinggi di halaman dinamis padahal halaman statis dan cache cepat, seperti dipetakan di artikel TTFB WordPress. Halaman tertentu lambat, arsip dan hasil pencarian, sementara homepage normal. Proses mysqld atau mariadbd duduk di konsumsi CPU tertinggi saat jam ramai.

Penanda kedua adalah kelambatan yang memburuk proporsional dengan trafik. Pola ini membedakan query lambat dari CPU kurang kuat: beban naik seiring konkurensi, bukan konstan sejak server sepi.

Prinsipnya tetap: gejala menentukan kapan log dinyalakan, log yang menentukan query mana yang diperbaiki. Jangan menyimpulkan tanpa data agregasi.

Cara Membaca Slow Log dan Menemukan Query Pembunuh Server

Log mentah adalah ribuan baris teks yang tidak bisa dibaca berurutan. Nilainya muncul setelah tiga tahap terurut: kumpulkan data bersih selama trafik normal, agregasi dan ranking dengan tool agar query pembunuh server mengapung ke atas, lalu bedah kandidat terburuk dengan EXPLAIN sampai keputusan perbaikan. Tahap yang dilewati berujung vonis salah: tanpa agregasi kamu menebak, tanpa EXPLAIN kamu buta penyebab. Diagram berikut merangkum alur lima tahap sampai verifikasi.

Mengaktifkan Log dan Mengumpulkan Data yang Bersih

Aktifkan log dengan ambang 1 sampai 2 detik, lalu biarkan berjalan 24 sampai 48 jam trafik normal, bukan saat sesi import sesekali. Siapkan rotasi log sejak awal agar disk aman, dan matikan log_queries_not_using_indexes bila file tumbuh terlalu berisik.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SHOW VARIABLES LIKE 'slow_query%';

Ingat bahwa SET GLOBAL hilang saat restart, jadi salin nilai final ke my.cnf bila ingin persisten. Catat rentang waktu pengumpulan agar hasilnya bisa dibandingkan dengan log verifikasi berikutnya secara adil.

Meringkas Log dengan mysqldumpslow dan pt-query-digest

Di sinilah frasa pt-query-digest wordpress menemukan konteksnya. mysqldumpslow adalah tool bawaan untuk pembacaan pertama: mengelompokkan query serupa dan mengurutkan berdasar total waktu. pt-query-digest dari Percona Toolkit memberi ranking dampak lengkap dengan persentase total waktu dan fingerprint query.

mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
pt-query-digest /var/log/mysql/mysql-slow.log --limit 10

Sinyal khas query WordPress buruk adalah rasio baris diperiksa yang jutaan berbanding baris dikirim yang sedikit. Prioritaskan berdasar kontribusi total waktu, bukan frekuensi mentah. Angka contoh di sini ilustrasi cara membaca, bukan pengukuran server mana pun.

Membedah Kandidat Terburuk dengan EXPLAIN

Jalankan EXPLAIN pada query peringkat atas untuk melihat rencana eksekusi. Baca tiga kolom kunci: type ALL berarti full scan, rows adalah perkiraan baris diperiksa, dan key NULL berarti tidak ada indeks terpakai. Cocokkan hasilnya dengan empat pola WordPress di section berikutnya.

EXPLAIN SELECT * FROM wp_postmeta WHERE meta_key = 'ilustrasi' AND meta_value = 'contoh';

Keputusan akhir selalu tiga jalur: tambah indeks, rewrite query, atau berikan cache. Query berulang yang sah adalah kandidat Redis Object Cache WordPress. Jangan menambah indeks buta tanpa mengukur dampaknya di log berikutnya.

Empat Pola Query WordPress yang Paling Sering Muncul di Log

Log WordPress jarang memberi kejutan: empat pola yang sama muncul berulang. WP_Query dengan meta_query atau ORDER BY meta_value memicu filesort karena filter meta tak didukung indeks bawaan. Scan autoload wp_options saat tabel membengkak; prosedur pembersihannya milik artikel Autoload Options WordPress.