Ukuran wp_options tetap naik meski kamu sudah menjalankan bersih bersih berkala seperti saran artikel Autoload Options WordPress. Baris transient yang lewat masa berlaku tidak hilang sendiri, dan sebagian tidak akan pernah hilang walau dibersihkan tiap minggu. Panduan wordpress transient api ini menjelaskan kenapa baris itu bertahan, kelas baris mana yang mustahil dilacak sistem, dan kapan membersihkan database bukan lagi jawaban yang benar.
Apa Itu WordPress Transients API
wordpress transient api adalah pasangan key value bermasa berlaku yang dipakai core dan plugin untuk cache ringan, penanda status, dan redirect singkat. Setiap key normal menulis dua baris di wp_options: _transient_key menyimpan nilai, _transient_timeout_key menyimpan tenggat. Sifat fundamentalnya: tanpa baris timeout, tidak ada mekanisme kedaluwarsa yang bisa bekerja.
Transient berbeda dari opsi biasa karena hidupnya sementara dan penghapusannya otomatis, setidaknya secara teori. Praktiknya penghapusan itu bersyarat, bukan garansi, dan setiap masalah menumpuk selalu kembali ke pertanyaan apakah baris timeout masih ada. Di sinilah pasangan timeout penentu nasib key menjadi konsep wajib sebelum menyentuh perintah apa pun.
Dua istilah kunci: persistent object cache, memori antar request yang mengubah tempat transient hidup, serta garbage collection, kerja pembersihan key lewat tenggat. Keduanya menentukan apakah targetmu baris database atau isi memori.
Mekanisme set_transient dan get_transient: Dua Lapis Kebersihan
Lapis pertama bekerja per key di dalam get_transient. Saat key dibaca dan timeoutnya sudah lewat, WordPress menghapus key itu lalu mengembalikan false agar nilainya dibangun ulang. Key yang tidak pernah dibaca lagi tidak pernah tersentuh lapis ini. Inilah lazy expired collection bawaan WordPress: bersih bersih yang menunggu dibaca, bukan yang berpatroli.
Lapis kedua adalah pemindai massal terjadwal. WordPress core mendaftarkan event cron delete_expired_transients yang berjalan per jam lewat WP Cron dan memanggil fungsi core bernama sama, delete_expired_transients(), untuk memindai pasangan timeout yang lewat tenggat. Yang pertama nama event jadwal, yang kedua nama fungsi. Keduanya butuh trafik nyata, karena WP Cron hanya terpicu request masuk, sehingga situs sepi membuat jadwal per jam molor tanpa kabar.
Ironi pemersatunya: kedua lapis hanya bisa menemukan key lewat baris _transient_timeout_key. Begitu baris itu hilang duluan, key pasangannya lenyap dari pandangan kedua mekanisme dan angka transient berhenti turun. Diagram berikut merangkum tiga nasib key dari satu titik tulis.
Dua Mode Penyimpanan: Baris wp_options atau Memori Redis
Mode pertama adalah bawaan tanpa object cache: transient adalah baris wp_options biasa, dan ukurannya ikut terhitung pada audit artikel Autoload Options WordPress. Setiap key menambah baris dan setiap pembacaan berarti query. Pada mode inilah seluruh prosedur di artikel ini relevan penuh.
Mode kedua aktif begitu persistent object cache terpasang: nilai transient wordpress hidup di memori dan baris database nyaris tidak tersentuh. Perbandingan transient vs redis object cache ini menentukan diagnosis, karena perintah yang menyasar tabel tidak menyentuh nilai yang dipakai. Ada jebakan ketiga, object cache non persisten, yang menyimpan nilai hanya selama satu request, sehingga transient tampak terhapus sendiri padahal tidak pernah masuk database. Tabel berikut memetakan dua mode penyimpanan transient plus jebakan ketiganya.
| Mode Object Cache | Di Mana Nilai Hidup | Efek ke Tabel wp_options |
|---|---|---|
| Tanpa object cache bawaan | Baris _transient_key dan _transient_timeout_key di wp_options | Baris bertambah tiap key dibuat, ukuran tabel ikut naik dan masuk hitungan audit autoload |
| Object cache non persisten | Memori selama satu request, hilang tiap request berakhir | Baris database tidak bertambah, tetapi key tak tertulis terbaca ulang sebagai kosong berulang kali |
| Persistent object cache Redis | Memori Redis yang bertahan antar request | Baris database praktis tidak tersentuh, mengukur dan membersihkan wp_options tidak lagi mencerminkan beban transient |
Tiga Kelas Transient yang Jarang Dibahas
Kelas normal punya pasangan timeout lengkap dan ikut terbuang kedua lapis pembersihan. Bentuk barisnya rapi: satu baris data dan satu baris tenggat. Kelas ini bukan masalah.
Kelas yatim piatu lahir saat baris _transient_timeout_key terhapus optimizer atau perintah hapus opsi, sementara baris _transient_key bertahan. Key ini mustahil ditemukan pemindai massal maupun pembacaan ulang. Inilah baris yatim piatu tak terlacak yang membuat angka tidak pernah turun walau pembersihan dijadwalkan tiap malam. Pola baris ketiga kelas berikut memakai nama key ilustrasi, bukan hasil ukur server mana pun.
normal : _transient_contoh + _transient_timeout_contoh
piatu : _transient_contoh (pasangan timeout hilang)
tanpa batas: _transient_contoh (baris timeout tidak pernah ditulis)Baris timeout adalah satu-satunya petunjuk yang membuat sistem bisa menemukan key-nya sendiri. Ketiadaan baris itu bukan kondisi bersih, melainkan key yang sudah tak terlacak.
Kelas tanpa batas lahir dari kesalahan desain plugin: set_transient dipanggil tanpa argumen masa berlaku sehingga baris timeout tidak pernah ada sejak awal. Key ini tidak punya jalur kedaluwarsa, dan satu satunya jalan bersih adalah penghapusan manual. Selama plugin penulisnya belum diperbaiki, key baru sejenis terus lahir tiap fitur itu berjalan. Rangkuman tiga kelasnya sudah tertulis di blok kode beda baris di atas.
Cara Membersihkan Transient WordPress dengan Aman dan Terukur
Frasa cara membersihkan transient wordpress terdengar sepele sampai salah perintah menghapus cache aktif, atau hapus sepihak melahirkan baris yatim piatu baru. Urutannya: ukur, amankan salinan tabel, bersihkan lewat jalur tepat, lalu jadwalkan dan verifikasi.
Hitung Dulu: Berapa Key yang Ekspirasi dan Berapa yang Yatim Piatu
Langkah pertama adalah pengukuran read only dengan dua hitungan. Query pertama menghitung key yang tenggatnya sudah lewat. Query kedua menghitung baris data tanpa pasangan timeout, populasi yang tidak pernah bergerak bila hanya mengandalkan mekanisme bawaan. Angka contoh di sini ilustrasi cara membaca hasil, bukan patokan server mana pun.
SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();
SELECT COUNT(*) FROM wp_options d LEFT JOIN wp_options t ON t.option_name = CONCAT('_transient_timeout_', SUBSTRING(d.option_name, 12)) WHERE d.option_name LIKE '_transient_%' AND d.option_name NOT LIKE '_transient_timeout_%' AND t.option_name IS NULL;Pilih Jalur: WP-CLI, Plugin Maintenance, atau Delete SQL Berpasangan
Langkah kedua memilih jalur sesuai populasi. Perintah wp transient delete tanpa flag menyasar key lewat tenggat saja, sehingga cache aktif tetap utuh. Varian delete expired transients wp cli berflag --all memaksa hapus seluruh key termasuk yang masih hidup, jadi jalankan di jendela trafik rendah. Delete SQL hanya untuk baris yatim piatu dan wajib berpasangan satu transaksi, karena hapus sepihak menciptakan masalah baru. Amankan salinan wp_options dulu, dan siapkan maintenance window singkat bila situs ramai.
wp transient delete --expired
wp transient delete --all
START TRANSACTION;
DELETE d, t FROM wp_options d LEFT JOIN wp_options t ON t.option_name = CONCAT('_transient_timeout_', SUBSTRING(d.option_name, 12)) WHERE d.option_name LIKE '_transient_%' AND d.option_name NOT LIKE '_transient_timeout_%' AND t.option_name IS NULL;
COMMIT;| Jalur | Kelebihan | Syarat Wajib |
|---|---|---|
wp transient delete tanpa flag | Menyasar hanya key yang sudah lewat tenggat, transient hidup tetap utuh | Butuh WP CLI dan akses database, tidak menyentuh baris yatim piatu |
wp transient delete --all | Sekali jalan untuk seluruh key, cepat untuk situs yang lama tertinggal | Menghapus key yang masih hidup, jalankan di jendela trafik rendah |
| Delete SQL berpasangan manual | Satu satunya jalur yang menyentuh baris yatim piatu, kontrol penuh atas cakupan | Backup wp_options dulu, hapus data dan timeout satu transaksi, hindari request paralel yang menulis key sama |
Jadwalkan Ulang dan Pastikan WP-Cron Masih Hidup
Langkah ketiga memasang jadwal pembersihan lewat cron server dan memastikan hook pemindai bawaan masih aktif, karena hook itu berjalan lewat WP Cron yang bisa saja sudah dimatikan mengikuti panduan Disable WP-Cron. Pastikan pemindai per jam masih terdaftar, lalu hitung ulang kedua query 24 jam kemudian. Diagram berikut merangkum siklus lima tahap sampai jadwal stabil. Verifikasi ini sama dengan artikel Slow Query Log WordPress: selesai hanya bila hitungan yatim piatu ikut turun lalu stabil.
Ketika Membersihkan Database Justru Salah Diagnosis
Begitu persistent object cache aktif, data transient wordpress tidak lagi membebani database, sehingga membersihkan baris wp_options menjadi kegiatan tanpa target. Perbandingan transient vs redis object cache di Section 3 kini berbalik menjadi vonis: yang benar adalah membersihkan memori cache, mencari plugin yang menulis transient tanpa batas, dan memastikan cron tetap berjalan. Detail mode memori milik artikel Redis Object Cache WordPress, cukup taut tanpa mengulang cara pasangnya.
Di kondisi ini yang perlu ditindak adalah populasi lain, yaitu baris autoload milik artikel Autoload Options WordPress. Jangan campur kedua pekerjaan dalam satu perintah, karena target, risiko, dan cara verifikasinya berbeda. Ukur ulang ukuran tabel setelah pembersihan, dan bila angkanya tidak bergerak sementara keluhan performa hilang, diagnosis memori itulah yang benar sejak awal, alias salah sasaran sejak diagnosis awal.
Transient dalam Peta Klaster Performa Server
Gejala luar terbaca lewat waktu muat artikel TTFB WordPress, lalu lapisan pembaca data per request adalah autoload wp_options milik artikel Autoload Options WordPress. Lapisan anti query berulang adalah Redis milik artikel Redis Object Cache WordPress, lapisan penjadwalan adalah WP Cron milik artikel Disable WP-Cron, lapisan RAM adalah buffer pool milik artikel InnoDB Buffer Pool WordPress, dan lapisan indeks milik artikel Database Indexing WordPress, dengan verifikasi sejalan artikel Slow Query Log WordPress.
Penanda batas: indeks tidak menolong di sini, karena masalahnya bukan meta_query melainkan baris opsi yang tumbuh dan tidak pernah hilang. Artikel ini tidak mengulang ambang autoload, cara pasang Redis, konfigurasi cron, parameter slow log, maupun prosedur indeks, semuanya cukup ditaut sebagai peta, bukan isi.
Rekomendasi Hosting untuk Website dengan Tabel wp_options yang Membesar
Mayoritas website cukup di Cloud Hosting Mordenhost: lingkungan server yang dikonfigurasi dan dipantau sysadmin internal, plus dukungan teknis yang memisahkan penyebab plugin dari penyebab server. Jalur ini cocok selama tabel masih wajar dan kebutuhanmu diagnosis benar, bukan akses database langsung tiap hari.
Pemilik situs dengan tabel wp_options besar, penghapusan berpasangan terjadwal, cron di luar WP Cron, dan analisis sebelum sesudah yang rutin cocok di Managed VPS Mordenhost: akses penuh konfigurasi database, eksekusi perintah langsung, tuning engine InnoDB, serta bantuan membaca hasil pengukuran, mulai Rp950.000 per bulan. Verifikasi harga di halaman produk sebelum memesan.
Kesimpulan
Membersihkan transient bukan tombol periodik, melainkan keputusan bersyarat ukur dulu. Keberhasilan bukan banyaknya baris terhapus, melainkan key yatim piatu ikut bersih dan jumlahnya stabil setelah jadwal dipasang.
Kalau fondasi server masih kabur, baca dulu memahami cara kerja hosting sebelum menjadwalkan pembersihan apa pun di situs produksi.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat soal penghapusan otomatis, keamanan hapus massal, beda cache Redis, dan penumpukan saat cron jalan.
Apakah transient yang sudah lewat masa berlaku otomatis terhapus?
Tidak selalu. Dua jalur wordpress transient api menunggu pemicu: lapis per key menunggu dibaca ulang, lapis massal menunggu jadwal per jam. Keduanya butuh trafik dan pasangan timeout yang masih ada.
Apakah aman menghapus semua transient sekaligus?
Tergantung perintahnya. Tanpa flag, delete expired transients wp cli hanya menyasar key lewat tenggat. Dengan flag --all, seluruh key terhapus termasuk yang masih hidup, sehingga situs harus membangun ulang cache aktif.
Transient di wp_options sama dengan cache Redis?
Tidak. Transient wordpress di tabel hanya satu dari dua mode penyimpanan. Tanpa object cache, transient memang baris wp_options. Dengan persistent object cache, nilainya di memori dan bersih bersih tabel tidak menyentuh nilai aktif.
Kenapa transient saya tetap menumpuk padahal cron sudah jalan?
Tiga sebab paling sering. Panduan cara membersihkan transient wordpress di atas menunjukkan key tanpa batas tanpa tenggat, baris piatu tak terlihat pemindai, atau hook per jam tidak aktif meski cron utama jalan.
Butuh bantuan membaca hasil hitungan transient atau memilih paket yang pas? Hubungi WhatsApp Mordenhost dan tim kami membantu memetakan langkah berikutnya.
