WordPress veritabanı optimizasyonu, sitenizin arka planda büyüyen ve genellikle fark edilmeyen bir sorununu çözer: zamanla şişen wp_options tablosu ve gereksiz veri birikimi. Site hızlı görünse bile, veritabanı arka planda binlerce gereksiz satır taşıyorsa, özellikle yoğun trafik anlarında sorgu süreleri uzar ve paylaşımlı hosting ortamlarında kaynak limitlerine daha çabuk çarpılır. Bu rehberde wp_options şişmesinin nedenlerini, nasıl tespit edileceğini ve güvenli temizlik adımlarını ele alıyoruz.
wp_options Tablosu Neden Şişer?
WordPress, eklentilerin ve temaların geçici verilerini (transient) ve ayarlarını wp_options tablosunda saklar. Sorun, birçok eklentinin bu geçici kayıtları süresi dolduğunda otomatik olarak temizlememesi. Zamanla tabloda binlerce, bazen yüz binlerce süresi geçmiş transient satırı birikebilir. Bu durum özellikle şu senaryolarda hızlanır: sık eklenti değiştirme, cache eklentilerinin yanlış yapılandırılması, e-ticaret eklentilerinin sepet/oturum verilerini transient olarak tutması ve düzenli yedekleme sırasında eski verinin temizlenmemesi.
Güncel WordPress’te autoload yalnızca yes değildir; varsayılan yüklenen değerler yes, on, auto-on ve auto’dur. Eklentiler/filter bu kapsamı daraltabilir. Otomatik yüklenen veriler alloptions nesnesi içinde önbelleğe alınabilir; her sayfa isteğinde bütün satırların yeniden SQL ile çekildiği varsayımı doğru değildir.
WordPress Veritabanı Optimizasyonu: Sorunu Nasıl Tespit Edersiniz?
Temizliğe başlamadan önce sorunun büyüklüğünü ölçmek gerekir. Aşağıdaki SQL sorgusu, wp_options tablosundaki en büyük autoload yüküne sahip kayıtları listeler:
SELECT option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY boyut DESC
LIMIT 20;Toplam autoload boyutunu görmek için:
SELECT SUM(LENGTH(option_value)) AS toplam_boyut_byte
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Autoload boyutunu, kullanılan sürümün Site Health değerlendirmesi ve gerçek PHP bellek/sorgu ölçümleriyle inceleyin. Bir MB evrensel güvenli sınır değildir. Çok satır bulunması veya bir option’ın büyük olması tek başına silme gerekçesi sayılmaz; kaydın sahibi ve kullanımı belirlenmelidir.
Yaygın Şişme Kaynakları Tablosu
| Kaynak | Belirti | Tipik Çözüm |
|---|---|---|
| Süresi dolmuş transientler | option_name içinde “_transient_” ön eki, sayısı binleri bulur | Süresi geçmiş kayıtları toplu silme |
| Devre dışı eklenti kalıntıları | Kaldırılan eklentiye ait ayar satırları hâlâ duruyor | Eklenti verilerini manuel temizleme |
| Yanlış yapılandırılmış cache eklentisi | Autoload boyutu sürekli büyüyor | Cache eklentisi ayarlarını gözden geçirme |
| Post revision birikimi | wp_posts tablosu aşırı büyümüş | Revizyon sayısını sınırlama |
| Spam/onaysız yorumlar | wp_comments tablosunda gereksiz kayıt | Düzenli yorum temizliği |
Güvenli Temizlik Adımları
Veritabanı üzerinde doğrudan işlem yapmadan önce tam bir yedek alınması önemle önerilir; bu adım atlanmamalı çünkü yanlış bir DELETE sorgusu geri alınamaz veri kaybına yol açabilir.
Adım Adım Uygulama
- Veritabanının tam yedeğini alın (hosting panelinden veya bir yedekleme eklentisiyle).
- Yukarıdaki sorgularla mevcut autoload yükünü ve en büyük kayıtları tespit edin.
- Süresi dolmuş transientleri temizleyin. Bunun için WP-CLI kullanmak manuel SQL’den daha güvenlidir:
wp transient delete --expired - Kullanılmayan eklentileri kaldırırken “veri de silinsin mi” seçeneğini kontrol edin; bazı eklentiler kaldırıldığında ayarlarını veritabanında bırakır.
- Post revizyon sayısını
wp-config.phpiçindedefine('WP_POST_REVISIONS', 5);gibi bir sınırla kısıtlayın. - OPTIMIZE TABLE her temizlikten sonra zorunlu değildir; InnoDB’de yeniden oluşturma, disk alanı ve kilitlenme etkisi yaratabilir. Önce veri tabanı motoru ve sağlayıcı önerisiyle gereksinimi belirleyin; kritik trafiğin dışında geri dönüşü test edilmiş yedekle planlayın.
- Site hızını temizlik öncesi ve sonrası karşılaştırarak (örneğin sayfa yükleme süresiyle) etkiyi doğrulayın.
Manuel SQL sorguları yerine süresi dolmuş transientleri temizleyen güvenilir bir eklenti kullanmak, özellikle veritabanı sorgularına aşina olmayan kullanıcılar için daha güvenli bir yol. Yine de eklenti seçerken güncel tutulan, çok sayıda aktif kurulumu olan ve düzenli destek alan seçenekleri tercih etmek önemli.
Bu İşlem Diğer Hız Optimizasyonlarıyla Nasıl İlişkili?
Veritabanı optimizasyonu tek başına bir mucize çözüm değil; sitenizin genel hız stratejisinin bir parçası olarak düşünülmeli. Örneğin önbellekleme (caching) katmanınız doğru yapılandırılmamışsa, veritabanı her sayfa isteğinde yeniden sorgulanmaya devam eder ve temizliğin faydası sınırlı kalır. Benzer şekilde, görsel optimizasyonu ve sunucu tarafı sıkıştırma gibi önlemler de veritabanı temizliğiyle birlikte uygulandığında toplam etkiyi büyütür. Yani wp_options temizliği, izole bir işlem değil, kapsamlı bir performans kontrol listesinin parçalarından biri olarak ele alınmalı.
Paylaşımlı hosting ortamında bu adım özellikle önemli, çünkü bu tür ortamlarda veritabanı sorgu sayısı ve süresi genellikle CPU ve bellek limitleriyle doğrudan ilişkili. Şişmiş bir wp_options tablosu, limitlere daha hızlı yaklaşılmasına ve “kaynak aşıldı” hatalarının daha sık görülmesine neden olabilir.
Sorunu Uzun Vadede İzlemek: Hangi Araçlar Yardımcı Olur?
Tek seferlik bir temizlik, sorunu geçici olarak çözer; ancak eklentiler ve temalar yeni veri üretmeye devam ettiği sürece wp_options tablosu zamanla tekrar şişebilir. Bu nedenle düzenli izleme, tek seferlik temizlikten daha değerli bir alışkanlık. Geliştirici odaklı bir eklenti olan Query Monitor, hangi eklentinin kaç sorgu çalıştırdığını ve sorguların hangi bileşen tarafından çalıştırıldığını ve toplam sürelerini sayfa bazında gösterir; bu, şişmenin kaynağını tahmin etmek yerine doğrudan gözlemlemeyi sağlar.
Hosting panelinizde phpMyAdmin veya benzeri bir veritabanı yönetim aracına erişiminiz varsa, tabloların boyutunu düzenli olarak (örneğin aylık) kontrol etmek de basit ama etkili bir alışkanlık. Çoğu kontrol panelinde “Veritabanları” bölümünde her tablonun boyutu satır satır listelenir; wp_options tablosunun diğer tablolara oranla anormal büyüdüğünü fark ettiğinizde, temizlik zamanı gelmiş demektir.
İzleme Kontrol Listesi
- Aylık olarak toplam veritabanı boyutunu ve wp_options tablosunun payını not edin.
- Yeni bir eklenti kurduktan sonra autoload boyutunda ani bir artış olup olmadığını kontrol edin.
- Kaldırdığınız eklentilerin veri bıraktığını fark ederseniz, ilgili option_name kayıtlarını temizleyin.
- Yedekleme sıklığınızı, veritabanı boyutunuzla orantılı şekilde ayarlayın; çok büyük bir veritabanı yedekleme süresini de uzatır.
Ne Sıklıkla Optimizasyon Yapılmalı?
Kesin bir kural yok, ama pratikte orta trafikli bir site için üç ayda bir kontrol makul bir başlangıç noktası. Yüksek trafikli, çok eklentili veya sık güncellenen bir e-ticaret sitesinde bu süre aylığa kadar inebilir. En pratik yaklaşım, otomatik bir izleme eklentisiyle autoload boyutunu düzenli takip etmek ve belirlenen eşik aşıldığında temizlik sürecini tetiklemek.
Sıkça Sorulan Sorular
wp_options tablosu ne kadar büyükse sorun sayılır?
Tek bir evrensel boyut sınırı yoktur. Site Health uyarısını, PHP bellek sınırını, kayıtların gerçekten kullanılıp kullanılmadığını ve ölçülen sorgu süresini birlikte inceleyin.
Veritabanı temizliği siteyi bozabilir mi?
Yanlış veya dikkatsiz yapılan manuel SQL silme işlemleri veri kaybına yol açabilir. Bu yüzden işlem öncesi tam yedek almak ve mümkünse güvenilir araçlar (WP-CLI, test edilmiş eklentiler) kullanmak önerilir.
WP-CLI olmadan bu temizliği yapabilir miyim?
Evet, phpMyAdmin üzerinden manuel sorgularla veya güvenilir bir temizlik eklentisiyle de yapılabilir; ancak WP-CLI daha hızlı ve tekrarlanabilir bir yöntem sunar.
Post revizyonlarını tamamen kapatmalı mıyım?
Tamamen kapatmak yerine sınırlamak (örneğin son 5 revizyon) genellikle daha dengeli bir yaklaşım; revizyonlar içerik geri alma açısından faydalı olabilir.
Optimizasyon sonrası hızda ne kadar iyileşme beklenir?
Bu, tablonun ne kadar şişmiş olduğuna bağlı olarak değişir; ağır şişmiş sitelerde gözle görülür bir iyileşme olası, ancak zaten temiz bir veritabanında etkisi sınırlı kalır.
wp_ örnek ön ektir; gerçek tablo ön ekini kullanın. Kalıcı object cache varsa transient’ler veritabanı dışında tutulabilir. Query Monitor sorguların kaynağını gösterir ama bütün autoload kayıtlarının hangi eklentiye ait olduğunu veya satır başına yükleme süresini kanıtlamaz. WP_POST_REVISIONS sınırı mevcut bütün revizyonları hemen temizlemez. Devre dışı eklenti ayarı yeniden kullanım/geri dönüş için gerekli olabilir; ön ek eşleşmesiyle toplu silmeyin.
Kaynak: WordPress — Autoload değerleri.
