WordPress Veritabanı Optimizasyonu ve Temizliği

Yıllarca çalışan bir WordPress kurulumunda asıl yavaşlama çoğu zaman tema veya eklentilerden değil, sessizce büyüyen veritabanından gelir. Her taslak kaydı, her süresi dolmuş transient ve her spam yorum, sorgu sürelerini uzatan ölü ağırlık haline gelir. Burada veritabanını gerçekten neyin şişirdiğini, hangi tabloların nasıl temizlendiğini ve InnoDB tarafında nelere dikkat edilmesi gerektiğini adım adım ele alıyoruz.

Veritabanını Neler Şişirir?

WordPress, içeriğin yanında çok sayıda yardımcı kaydı da aynı tablolarda tutar. Zamanla bu kayıtlar asıl içerikten daha fazla yer kaplar hale gelir. En sık karşılaşılan şişme kaynakları şunlardır:

• Post revizyonları: Her kaydetmede wp_posts tablosuna yeni bir revision satırı eklenir; uzun bir yazının onlarca kopyası birikebilir.
• Süresi dolmuş transientler: wp_options içindeki _transient_ ve _transient_timeout_ kayıtları temizlenmediğinde yüzlerce satıra ulaşabilir.
• Spam ve çöp yorumlar: wp_comments ve ilişkili wp_commentmeta satırları silinmeden bekler.
• Yetim metadata: İlişkili gönderi silindiği halde wp_postmeta içinde kalan kayıtlar.
• Otomatik taslaklar (auto-draft): Hiç yayımlanmadan terk edilen yazılar.

Yedek Almadan Hiçbir Şeye Dokunmayın

Temizliğe başlamadan önce mutlaka tam bir veritabanı yedeği alın. Komut satırına erişiminiz varsa mysqldump en güvenilir yöntemdir:

mysqldump -u wp_user -p --single-transaction --quick \
  --default-character-set=utf8mb4 wp_database > wp_yedek_$(date +%F).sql

--single-transaction parametresi InnoDB tablolarında siteyi kilitlemeden tutarlı bir yedek alır. Paylaşımlı bir ortamdaysanız ve SSH erişiminiz yoksa cPanel üzerinden phpMyAdmin'in Export sekmesini ya da hosting panelindeki yedekleme aracını kullanabilirsiniz.

Revizyonları ve Çöpü Temizlemek

İçeriği bozmadan en çok yer kazandıran işlem revizyon temizliğidir. Tek seferlik bir SQL ile geçmiş revizyonları silebilirsiniz:

DELETE a, b, c FROM wp_posts a
  LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
  LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
   OR option_name LIKE '\_site\_transient\_%';

Düzenli kontrolden geçirmek isterseniz revizyon sayısını sınırlamak en temiz çözümdür. wp-config.php dosyasına ekleyeceğiniz şu satır, her yazı için en fazla 5 revizyon tutar:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 7 );

WP-CLI ile Hızlı Bakım

Sunucuda WP-CLI varsa temizlik ve optimizasyon tek satırlarla yapılır. Bu yöntem panel üzerinden tıklamaktan çok daha hızlı ve denetlenebilirdir:

# Süresi dolmuş transientleri sil
wp transient delete --expired

# Tüm veritabanı tablolarını optimize et
wp db optimize

# Revizyonları temizle (eklenti gerektirir veya doğrudan sorgu)
wp post delete $(wp post list --post_type='revision' --format=ids) --force

Otomatik bir kabuk betiğiyle bu komutları haftalık cron'a bağlayarak bakım yükünü tamamen elinizden alabilirsiniz. Yönetilen bir WordPress hosting paketinde WP-CLI çoğunlukla hazır gelir, böylece SSH oturumunda ek kurulum yapmadan bu komutları çalıştırabilirsiniz.

Tabloları Optimize Etmek ve Motor Seçimi

Çok sayıda DELETE işleminden sonra tablolarda boşluk (fragmentation) oluşur. MyISAM tablolarında OPTIMIZE TABLE bu boşluğu fiziksel olarak geri kazanır. InnoDB'de ise OPTIMIZE TABLE arka planda tabloyu yeniden oluşturur ve genellikle ALTER TABLE ... ENGINE=InnoDB ile aynı etkiyi verir.

OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments;

Eski kurulumlarda bazı tablolar hâlâ MyISAM olabilir. Modern MySQL ve MariaDB sürümlerinde InnoDB'ye geçmek, satır seviyesinde kilitleme ve daha iyi kurtarma davranışı sağladığı için yaklaşık her senaryoda önerilir:

Bogahost Önerisi: Production sitede ağır SQL sorgularını doğrudan canlı veritabanında denemeyin. Önce bir staging kopyası oluşturup işlemi orada doğrulayın, ardından düşük trafikli saatlerde uygulayın. Bu yaklaşım, beklenmedik bir kilit veya hatalı WHERE koşulunun siteyi düşürmesini engeller.

İndeksler ve Yavaş Sorguları Bulmak

Tablolar temizlendiğinde bile yanlış kurgulanmış sorgular yavaşlık yaratabilir. Hangi sorguların sürüklediğini görmek için MySQL'in slow query log'unu kısa süreliğine açabilirsiniz:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Özellikle wp_postmeta tablosundaki meta_key taramaları, eklentilerde sık görülen bir darboğazdır. Çok büyük metadata tablolarında meta_key üzerine bileşik bir indeks eklemek sorgu planını belirgin biçimde iyileştirebilir. Değişiklik öncesi EXPLAIN çıktısını incelemek, indeksin gerçekten kullanılıp kullanılmadığını görmenizi sağlar.

Düzenli Bakım Planı

Tek seferlik temizlik, alışkanlık haline gelmezse birkaç ay içinde aynı noktaya dönersiniz. Sürdürülebilir bir döngü için şu kontrolleri takvime bağlayın:

• Haftalık: Süresi dolmuş transientleri sil ve çöp/spam yorumları boşalt.
• Aylık: Tabloları optimize et ve revizyon birikimini gözden geçir.
• Üç ayda bir: Pasif eklentilerin bıraktığı yetim wp_options ve wp_postmeta kayıtlarını ara.
• Sürüm yükseltmelerinden önce: Mutlaka tam yedek al ve staging'de doğrula.

Birden çok siteyi tek panelde barındırdığınız bir web hosting ortamında bu bakım rutinini merkezi bir cron betiğiyle tüm kurulumlara uygulamak, manuel iş yükünü ciddi biçimde azaltır.

Özet

Veritabanı optimizasyonu, sihirli bir tek tıkla çözülen bir iş değil; revizyon sınırı, transient temizliği, tablo optimizasyonu ve doğru depolama motorunun bir araya geldiği sürekli bir disiplindir. Yedeğinizi alıp staging'de doğruladıktan sonra bu adımları rutine bağladığınızda, WordPress siteniz yıllar geçse de ilk günkü çevikliğine yakın kalır.