WordPress sitenizin kalbi veritabanıdır. Yazılarınız, sayfalarınız, yorumlarınız, kullanıcı bilgileriniz ve sitenizin tüm ayarları bu veritabanında saklanır. Her sayfa açıldığında WordPress bu veritabanına onlarca sorgu göndererek içeriği bir araya getirir. Zamanla bu veritabanı kaçınılmaz olarak şişer: her düzenlemede biriken yazı revizyonları, çöp kutusundaki içerikler, spam yorumlar, süresi geçmiş geçici kayıtlar ve çoktan sildiğiniz eklentilerden arta kalan tablolar üst üste yığılır. Sonuçta her sorgu biraz daha uzun sürer ve siteniz farkında olmadan yavaşlar.
Bu rehberde önce veritabanının neden ve nasıl şiştiğini, bu şişkinliğin site hızına somut etkisini ve mevcut durumu nasıl ölçeceğinizi ele alacağız. Ardından temizliği hem bir eklentiyle güvenle hem de phpMyAdmin üzerinden elle SQL ile nasıl yapacağınızı adım adım göstereceğiz. Revizyon sınırlama, transient temizleme, yetim (orphaned) metadata, en tehlikeli sorunlardan biri olan wp_options autoload devleri ve tabloları onarma gibi konuları uygulamalı örneklerle anlatacağız. En baştan altını çizelim: bu işlemlerin hiçbirine tam bir yedek almadan başlamayın.
Veritabanı Neden Zamanla Şişer?#
WordPress kullandıkça, arka planda pek çok gereksiz veri birikir. Başlıca kaynaklar şunlardır:
- Yazı revizyonları. Bir yazıyı her kaydettiğinizde WordPress önceki hâlini bir revizyon olarak saklar. Uzun süredir düzenlediğiniz bir yazının onlarca revizyonu birikmiş olabilir; bunların hepsi
wp_poststablosunda yer kaplar. - Otomatik taslaklar (autosave). WordPress yazarken düzenli aralıklarla otomatik taslak kaydeder. Bunların çoğu asla işe yaramaz ama tabloda kalır.
- Çöp ve spam yorumlar. Silinmiş ama çöp kutusunda bekleyen yorumlar ve onay bekleyen spam yorumlar birikir.
- Süresi geçmiş transient kayıtlar. Transient, geçici verileri (örneğin bir eklentinin ürettiği önbellek) tutan kayıtlardır. Süresi dolduğunda WordPress bunları her zaman anında temizlemez;
wp_optionstablosunda birikirler. - Eklenti ve tema artıkları. Kaldırdığınız eklentiler çoğu zaman kendi tablolarını ve ayarlarını veritabanında bırakır. Sildiğiniz bir eklentinin izleri aylar sonra bile orada durabilir.
- Şişmiş
wp_optionsautoload verisi. Bazı eklentiler, her sayfa açılışında otomatik yüklenen (autoload) devasa kayıtlar bırakır. Bu, şişkinliğin en sinsi ve en zararlı türüdür; ayrı bir başlıkta ele alacağız.
Bu birikimler tek başına küçük görünse de yıllar içinde birleşerek veritabanını yüzlerce megabayta kadar büyütebilir. Önemli olan boyut kadar, bu verilerin sorguları ne kadar yavaşlattığıdır.
Şişkinliğin Site Hızına Etkisi#
Şişmiş bir veritabanı sitenizi birkaç şekilde yavaşlatır. Her sayfa yüklendiğinde WordPress veritabanına sorgu gönderir; tablolar ne kadar büyük ve dağınıksa, bu sorguların yanıt süresi o kadar uzar. Özellikle wp_options tablosundaki autoload verisi her istekte baştan yüklendiği için, buradaki şişkinlik doğrudan her sayfanın açılış süresine biner.
Etkiler şöyle özetlenebilir:
- Sayfa açılış süresi uzar, ziyaretçi deneyimi bozulur.
- Sunucu her istekte daha fazla bellek ve işlemci harcar; kaynaklarınız çabuk tükenir.
- Yedekleme dosyaları gereksiz yere büyür, yedek alma ve geri yükleme yavaşlar.
- Yönetim paneli (özellikle yazı listesi ve düzenleme ekranları) yavaşlar.
Veritabanı temizliği, önbellekleme kadar gösterişli olmasa da hızlanma çalışmasının önemli bir parçasıdır. Genel bir performans çalışması planlıyorsanız WordPress hız optimizasyonu rehberimizdeki diğer adımlarla birlikte ele almanız en verimli sonucu verir.
Önce Ölçün: Mevcut Durumu Tespit Etme#
Temizliğe başlamadan önce sorunun boyutunu görmek gerekir. İki temel şeyi ölçün: veritabanının genel boyutu ve wp_options autoload verisinin ağırlığı.
Veritabanınızın toplam boyutunu ve tablo tablo dağılımını phpMyAdmin üzerinden kolayca görebilirsiniz; sol menüden veritabanınızı seçtiğinizde her tablonun boyutu listelenir. Hangi tabloların en çok yer kapladığını bir sorguyla da bulabilirsiniz:
SELECT table_name AS 'Tablo',
ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'Boyut_MB'
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length + index_length) DESC;
En kritik ölçüm ise autoload verisinin toplam boyutudur. Şu sorgu, her sayfa açılışında yüklenen verinin ne kadar olduğunu kilobayt cinsinden gösterir:
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_KB,
COUNT(*) AS kayit_sayisi
FROM wp_options
WHERE autoload = 'yes';
Genel bir kural olarak autoload verisi 800 KB - 1 MB'ı aşıyorsa dikkat etmeniz gerekir; bu değer birkaç megabayta ulaştıysa ciddi bir sorununuz var demektir. En büyük autoload kayıtlarını hangi eklentinin bıraktığını da görebilirsiniz:
SELECT option_name,
ROUND(LENGTH(option_value) / 1024, 2) AS Boyut_KB
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 20;
Bu üç ölçümü not alın; temizlik sonrası aynı sorguları çalıştırarak ne kadar kazandığınızı somut biçimde göreceksiniz.
Önemli Uyarı: Her Şeyden Önce Yedek Alın#
Bu rehberdeki elle SQL işlemleri geri döndürülemez. Yanlış bir DELETE sorgusu ya da bir yazım hatası, sitenizin tamamen çökmesine ya da içeriğinizin kalıcı olarak kaybolmasına yol açabilir. Bu yüzden herhangi bir sorgu çalıştırmadan önce mutlaka veritabanınızın tam bir yedeğini alın.
- phpMyAdmin ile: veritabanınızı seçin, üstteki "Dışa Aktar" (Export) sekmesine tıklayın ve SQL formatında indirin.
- Eklenti ile: UpdraftPlus gibi bir yedekleme eklentisiyle sitenizin ve veritabanının tam yedeğini alın.
- Barındırma paneli ile: cPanel veya sunucu panelinizdeki yedekleme aracını kullanın.
Yedeği aldıktan sonra, indirdiğiniz dosyanın gerçekten oluştuğunu ve boyutunun makul olduğunu (birkaç kilobayttan ibaret olmadığını) kontrol edin. Mümkünse temizliği önce bir test/hazırlık kopyasında deneyin. Bu uyarıyı ciddiye alın; deneyimli yöneticiler bile tek bir dikkatsiz sorguyla saatlerce süren kayıplar yaşayabilir.
Yöntem 1: Eklenti ile Güvenli Temizlik#
Kod ve SQL ile uğraşmak istemiyorsanız, en güvenli yol bir temizlik eklentisi kullanmaktır. En yaygın tercihler WP-Optimize ve Advanced Database Cleaner'dır. Bu eklentiler, riskli sorguları sizin adınıza kontrollü biçimde çalıştırır ve çoğu, işlem öncesi otomatik yedek alma seçeneği sunar.
WP-Optimize ile tipik bir temizlik akışı şöyledir:
- Eklentiyi Eklentiler > Yeni Ekle ekranından kurup etkinleştirin.
- Sol menüden WP-Optimize > Database ekranına gidin.
- Karşınıza çıkan onay kutularından temizlemek istediklerinizi seçin: yazı revizyonları, otomatik taslaklar, çöp/spam yorumlar, süresi geçmiş transient'ler.
- "Run all selected optimizations" butonuna basın.
Eklenti, hangi işlemin ne kadar yer kazandıracağını genellikle önceden gösterir. İlk kullanımda tüm seçenekleri körlemesine işaretlemek yerine, önce revizyon ve transient temizliği gibi güvenli olanlarla başlamanızı öneririz. Ayrıca birçok temizlik eklentisi, düzenli otomatik temizlik zamanlaması (haftalık gibi) kurmanıza da olanak tanır; bu, veritabanının tekrar şişmesini önlemenin pratik bir yoludur.
Yöntem 2: phpMyAdmin ve SQL ile Elle Temizlik#
Kontrolü tamamen elinizde tutmak isteyen ileri düzey kullanıcılar için SQL ile doğrudan müdahale mümkündür. Bu yöntemin güçlü ama riskli olduğunu tekrar hatırlatalım; yedeğiniz hazır olmadan tek bir sorgu bile çalıştırmayın. phpMyAdmin'in genel kullanımına hâkim değilseniz phpMyAdmin kullanımı rehberimize göz atın; sorgu çalıştırma için "SQL" sekmesini kullanacaksınız.
Aşağıdaki sorgular wp_ tablo öneki varsayar. Kurulumunuz farklı bir önek kullanıyorsa (örneğin wp7x_) sorgulardaki öneki ona göre değiştirin.
Eski yazı revizyonlarını silin:
DELETE FROM wp_posts WHERE post_type = 'revision';
Otomatik taslakları temizleyin:
DELETE FROM wp_posts WHERE post_status = 'auto-draft';
Çöp kutusundaki içerikleri kaldırın:
DELETE FROM wp_posts WHERE post_status = 'trash';
Spam ve çöp yorumları temizleyin:
DELETE FROM wp_comments
WHERE comment_approved = 'spam' OR comment_approved = 'trash';
Süresi geçmiş transient kayıtlarını silin:
DELETE FROM wp_options
WHERE option_name LIKE '\_transient\_%'
OR option_name LIKE '\_site\_transient\_%';
Her sorguyu tek tek çalıştırın ve etkilenen satır sayısını gözlemleyin. Bir sorgunun beklediğinizden çok daha fazla satırı etkilediğini görürseniz durun ve yedeğinizden geri dönmeyi düşünün.
Revizyon ve Transient Kontrolünü Kalıcı Hale Getirme#
Temizlik tek seferlik bir çözümdür; asıl amaç, veritabanının bir daha aynı hızda şişmesini önlemektir. Bunu wp-config.php dosyanıza ekleyeceğiniz birkaç sabitle sağlayabilirsiniz. Bu dosyayı FTP veya dosya yöneticisiyle açın ve /* That's all, stop editing! */ satırının üstüne şu tanımları ekleyin:
// Yazı başına en fazla 5 revizyon tut
define( 'WP_POST_REVISIONS', 5 );
// Otomatik kaydetme aralığını 5 dakikaya çıkar (varsayılan 60 sn)
define( 'AUTOSAVE_INTERVAL', 300 );
// Çöp kutusunu 7 günde bir otomatik boşalt
define( 'EMPTY_TRASH_DAYS', 7 );
WP_POST_REVISIONS değerini 5 gibi makul bir sayıya sabitlemek, revizyonların sonsuza dek birikmesini engellerken geri dönüş için yeterli bir geçmiş bırakır. Revizyonları tamamen kapatmak isterseniz değeri false yapabilirsiniz, ancak bu durumda yanlışlıkla sildiğiniz bir içeriğe geri dönemeyeceğinizi unutmayın. AUTOSAVE_INTERVAL süresini uzatmak, otomatik taslakların daha seyrek oluşmasını sağlar.
Transient'ler için ise genellikle ekstra bir sabit gerekmez; düzenli bir temizlik eklentisi ya da yukarıdaki SQL sorgusu süresi geçmişleri temizler. Kalıcı bir nesne önbelleği (Redis/Memcached) kullanıyorsanız transient'ler zaten veritabanı yerine bellekte tutulur ve wp_options şişkinliği bu yönden azalır.
Yetim Metadata ve wp_options Autoload Sorunu#
En çok görmezden gelinen ama en çok etki eden iki sorun bunlardır.
Yetim (Orphaned) Metadata#
Bir yazı silindiğinde ona bağlı meta veriler (wp_postmeta) her zaman temiz biçimde silinmez; bazı eklentiler artıklarını geride bırakır. Artık var olmayan bir yazıya bağlı bu "yetim" kayıtlar wp_postmeta tablosunu şişirir. Onları şu sorguyla temizleyebilirsiniz:
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;
Bu sorgu, karşılığında bir yazı bulunmayan tüm meta kayıtlarını siler. Aynı mantık yorumlara ait yetim metadata için de geçerlidir. Bu tür ileri sorgular ve JOIN yapısı hakkında daha fazla bilgi için MySQL veritabanı yönetimi rehberimiz iyi bir başlangıç noktasıdır.
wp_options Autoload Devlerini Düzeltme#
wp_options tablosunda autoload = 'yes' işaretli kayıtlar her sayfa açılışında yüklenir. Bir eklentinin oraya bıraktığı devasa bir kayıt, siteyi görünmez biçimde yavaşlatır. Ölçüm bölümündeki sorguyla en büyük autoload kayıtlarını tespit ettikten sonra, artık kullanmadığınız bir eklentiye ait olduğundan eminseniz o kaydı silebilir veya autoload'unu kapatabilirsiniz.
Belirli bir kaydın her istekte yüklenmesini durdurmak için (silmeden, sadece autoload'u kapatarak):
UPDATE wp_options SET autoload = 'no'
WHERE option_name = 'ornek_dev_kayit';
Buradaki option_name değerini, ölçüm sorgusunda tespit ettiğiniz gerçek kayıt adıyla değiştirin. Dikkat: hangi kaydın hangi eklentiye ait olduğundan emin olmadan silme yapmayın; aktif bir eklentinin kritik ayarını kaldırırsanız o eklenti bozulabilir. Emin değilseniz önce autoload'u no yapıp siteyi test edin, sorun çıkmazsa kalıcı olarak silin.
Tabloları Onarma ve WP-CLI ile Temizlik#
Silme işlemlerinden sonra tablolarda boşluklar (fragmentation) kalır. OPTIMIZE TABLE komutu bu boşlukları toplayarak tabloları yeniden düzenler ve disk alanını geri kazandırır:
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options, wp_comments, wp_commentmeta;
phpMyAdmin'de bunu sorgu yazmadan da yapabilirsiniz: tablo listesinde ilgili tabloları işaretleyip alttaki menüden "Optimize table" seçeneğini çalıştırmanız yeterlidir.
Sunucunuza SSH erişiminiz varsa, tüm bu işlemleri WP-CLI ile çok daha hızlı halledebilirsiniz. WP-CLI, WordPress'i komut satırından yöneten güçlü bir araçtır:
# Tüm revizyonları temizle
wp post delete $(wp post list --post_type='revision' --format=ids) --force
# Süresi geçmiş transient'leri sil
wp transient delete --expired
# Veritabanı tablolarını optimize et
wp db optimize
WP-CLI, özellikle çok sayıda siteyi yöneten kullanıcılar için işleri büyük ölçüde otomatikleştirir. Yine de bu komutları da yedek almadan çalıştırmayın; --force bayrağı çöp kutusunu atlayarak kalıcı silme yapar.
Son olarak, tüm bu bakımı düzenli bir programa bağlayın: ayda bir revizyon ve transient temizliği, üç ayda bir kapsamlı bir kontrol (autoload boyutu, yetim metadata, tablo optimizasyonu) ve her müdahale öncesi yedek. Bu ritmi oturttuğunuzda veritabanınız yıllarca sağlıklı ve hızlı kalır.
Sıkça Sorulan Sorular#
Veritabanı temizliği sitemi bozar mı?#
Doğru yapılırsa bozmaz; ama yanlış bir SQL sorgusu ya da yanlış kaydın silinmesi siteyi çökertebilir. Riski en aza indirmek için işlemden önce mutlaka tam yedek alın, mümkünse önce test kopyasında deneyin ve emin olmadığınız kayıtları silmeyin. SQL ile uğraşmak istemiyorsanız WP-Optimize gibi bir eklenti, işlemleri sizin adınıza kontrollü biçimde yaptığı için çok daha güvenlidir. Bir sorun çıkarsa yedeğinizden geri dönebilirsiniz.
Ne sıklıkla veritabanı temizliği yapmalıyım?#
Trafiğine ve içerik üretim hızına göre değişmekle birlikte, çoğu site için ayda bir revizyon ve transient temizliği yeterlidir. Üç ayda bir de autoload boyutu, yetim metadata ve tablo optimizasyonu gibi daha kapsamlı bir kontrol yapmak iyi bir alışkanlıktır. Çok aktif ya da çok eklentili sitelerde bu aralıkları kısaltabilirsiniz. Bir temizlik eklentisiyle otomatik zamanlama kurmak, bu bakımı elle hatırlamak zorunda kalmadan sürdürmenin en pratik yoludur.
wp_options autoload verisi neden bu kadar önemli?#
Çünkü autoload = 'yes' işaretli kayıtlar sitenizin her sayfa açılışında baştan yüklenir. Buradaki verinin toplam boyutu birkaç megabayta ulaştıysa, her ziyaretçi her istekte bu yükü taşır ve site görünmez biçimde yavaşlar. Genellikle bakımsız ya da silinmiş eklentiler oraya devasa kayıtlar bırakır. Autoload boyutunu düzenli olarak ölçmek ve gereksiz devleri temizlemek, çoğu zaman fark edilmeyen ama en etkili hız kazançlarından birini sağlar.
Yazı revizyonlarını tamamen kapatmalı mıyım?#
Tamamen kapatmak (WP_POST_REVISIONS değerini false yapmak) veritabanı şişkinliğini azaltır, ancak yanlışlıkla sildiğiniz ya da bozduğunuz bir içeriğe geri dönme imkânınızı da ortadan kaldırır. Çoğu kullanıcı için en dengeli çözüm, revizyonları kapatmak yerine makul bir sayıya (örneğin 5) sınırlamaktır. Böylece hem gereksiz birikimi önlersiniz hem de gerektiğinde son birkaç sürüme geri dönebilirsiniz. Çok sık düzenleme yaptığınız kritik içerikleriniz varsa bu sınırı biraz yüksek tutabilirsiniz.
Temizlik sonrası site boyutum küçülmedi, neden?#
DELETE sorguları verileri kaldırır ama MySQL tablolardaki fiziksel alanı otomatik olarak geri vermez; geride boşluklar (fragmentation) kalır. Bu boşlukları toparlayıp disk alanını geri kazanmak için silme işlemlerinden sonra OPTIMIZE TABLE komutunu çalıştırmanız gerekir. phpMyAdmin'de tabloları seçip "Optimize table" demeniz ya da wp db optimize komutunu kullanmanız yeterlidir. Bu adımdan sonra tablo boyutlarının belirgin biçimde küçüldüğünü görürsünüz.
Paylaşımlı hostingte de bu temizliği yapabilir miyim?#
Evet. WP-Optimize gibi eklentiler ve phpMyAdmin, paylaşımlı barındırma paketlerinin neredeyse tamamında kullanılabilir; cPanel üzerinden phpMyAdmin'e erişebilir ve yedek alabilirsiniz. Yalnızca WP-CLI erişimi bazı paylaşımlı planlarda kısıtlı olabilir; bu durumda eklenti veya phpMyAdmin yöntemini kullanırsınız. Kaynakları paylaşılan bir ortamda düzenli veritabanı bakımı, sitenizin ayrılan sınırlar içinde daha verimli çalışmasına da yardımcı olur.
Kapanış#
WordPress veritabanı, kullandıkça kaçınılmaz olarak revizyonlar, otomatik taslaklar, spam yorumlar, süresi geçmiş transient'ler, yetim metadata ve şişmiş autoload kayıtlarıyla dolar. Bu birikim her sorguyu biraz daha yavaşlatır ve zamanla sitenizin performansını gözle görülür biçimde düşürür. Çözüm; durumu ölçmek, temizliği eklentiyle ya da dikkatli SQL ile yapmak, revizyon ve transient kontrolünü wp-config.php sabitleriyle kalıcı hâle getirmek, autoload devlerini ve yetim kayıtları ayıklamak ve tabloları optimize etmektir. Ve her şeyin başında değişmez kural: hiçbir işleme yedek almadan başlamayın.
Bu bakımı düzenli bir programa oturttuğunuzda veritabanınız yıllarca hafif ve hızlı kalır. Sitenizin altındaki barındırma da en az veritabanı kadar önemlidir; NVMe diskli, güncel MySQL sürümü sunan bir WordPress hosting paketi, temiz bir veritabanının potansiyelini tam olarak ortaya çıkarır. Bakım, güncelleme ve optimizasyon işlerini kendiniz üstlenmek istemiyorsanız, düzenli veritabanı bakımını da kapsayan bir WordPress bakım hizmetiyle bu yükten tamamen kurtulabilirsiniz.