WordPress veritabanı neden şişer? Revizyon, transient ve autoload temizliği

Yavaş bir WordPress sitesine bakarken ilk açtığım şeylerden biri veritabanıdır. Yüz yazılık bir blogun veritabanı yüzlerce megabayt tutuyorsa, sorun büyük ihtimalle içerikte değil, zamanla biriken kalıntılardadır.

Başlamadan önce mutlaka bir veritabanı yedeği alın. Aşağıdaki sorguların hepsi silme işlemi yapar.

wp db export oncesi.sql

Örneklerde tablo öneki wp_ olarak yazıldı. Sizin önekiniz farklıysa (wp-config.php içindeki $table_prefix) ona göre değiştirin.

1. Önce ölçün

Hangi tablonun ne kadar yer kapladığını görmek için:

SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY mb DESC LIMIT 10;

Genelde şüpheliler wp_options, wp_postmeta ve eklentilerin kendi log tablolarıdır.

2. wp_options ve autoload

wp_options tablosundaki autoload sütunu açık olan satırlar, her sayfa yüklemesinde tek bir sorguyla belleğe alınır. Silinmiş eklentilerden kalan ayarlar ya da büyük önbellek verileri burada birikirse her ziyaret yavaşlar.

Toplam boyuta bakın:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS kb
FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Birkaç yüz KB normaldir. 1 MB'ın üstü dikkat çeker. En büyük satırları bulmak için:

SELECT option_name, ROUND(LENGTH(option_value) / 1024) AS kb
FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC LIMIT 20;

Listede artık kullanmadığınız bir eklentinin adını görüyorsanız o satırlar güvenle silinebilir. Aktif bir eklentiye ait büyük bir satır görüyorsanız silmeyin; o eklentinin ayarlarına ya da destek ekibine bakın.

WordPress 6.6 ile autoload değerleri on, off, auto gibi yeni biçimlere geçti. Bu yüzden sorgularda eski yes değerinin yanında yenilerini de saydım.

3. Süresi dolmuş transient'ler

Transient, eklentilerin geçici önbellek verisidir. Kalıcı bir nesne önbelleği (Redis, Memcached) yoksa wp_options tablosunda tutulur. Süresi dolanlar normalde zamanla temizlenir, ama WP-Cron düzgün çalışmıyorsa birikebilir.

WP-CLI ile güvenli temizlik:

wp transient delete --expired

Hepsini silmek de genellikle güvenlidir; eklentiler ihtiyaç duyduğunda yeniden oluşturur:

wp transient delete --all

4. Revizyonlar

Her "Güncelle" tıklaması bir revizyon oluşturur. Kaç tane olduğuna bakın:

SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

Silmenin en temiz yolu bir araçtır. WP-Sweep ya da WP-Optimize gibi eklentiler revizyonları ilişkili meta kayıtlarıyla birlikte siler. Çıplak bir DELETE sorgusu wp_postmeta içinde sahipsiz kayıtlar bırakır. Sonra ileriye dönük bir sınır koyun:

define( 'WP_POST_REVISIONS', 5 );

5. Sahipsiz meta kayıtları

Silinmiş yazılara ait meta kayıtlarını görmek için:

SELECT COUNT(*) FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Sayı yüksekse silebilirsiniz:

DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

6. Spam yorumlar ve çöp kutusu

wp comment delete $(wp comment list --status=spam --format=ids) --force
wp post delete $(wp post list --post_status=trash --format=ids) --force

Liste boşsa bu komutlar hata verir. Bu normaldir ve zararsızdır.

7. Eklenti log tabloları

Güvenlik, form ve e-posta eklentileri ziyaret ya da gönderim kayıtlarını kendi tablolarında tutar. Bunlar bazen gigabaytlara ulaşır. Önce eklentinin ayarlarında "kayıtları X gün sakla" gibi bir seçenek arayın; doğrudan tablo silmekten çok daha güvenlidir.

Sonrası

Büyük silme işlemlerinden sonra tabloları optimize ederek diskteki alanı geri kazanabilirsiniz:

wp db optimize

Bu temizliği yılda bir iki kez yapmak çoğu site için yeterli. Asıl kazanç ise nedenleri kapatmaktan gelir: Revizyon sınırı koyun, WP-Cron'u düzgün çalıştırın ve eklentileri silerken ayarlarını da kaldırmasını sağlayın.