WordPress Veritabanı Temizliği; Gerçek Sorgu ile Boyutu %80'e Kadar Azaltın

WordPress veritabanınız 400 MB ve sitenizde yalnızca 2 MB içerik var

Bu sahneyi bilirsiniz: phpMyAdmin'den wp_options tablosuna bir göz atarsınız ve gözünüz 350.000 satır sayısına takılır. Ya da wp_postmeta tablosunu açarsınız ve yalnızca 300 yazınız olmasına rağmen 120 bin satır görürsünüz. Veritabanı yedekleme işlemi 10 dakika sürer, WordPress yönetim sayfaları yavaşlar ve her eklenti kurduğunuzda site nefes alamıyormuş gibi olur.

Sorun WordPress'in kendisinde değil. Sorun, WordPress'in ve eklentilerin yıllar içinde veritabanında sessizce biriktirdiği şeylerde. İyi haber şu ki, bu boyutun çoğu birkaç basit sorguyla silinebilir. Eklenti olmadan, gereksiz risk olmadan, sadece saf SQL ile.

WordPress veritabanının boyutunu artıran dört şey

Sorgu yazmadan önce neyle karşı karşıya olduğumuzu bilmeliyiz. WordPress veritabanı şişkinliğinin dört ana kaynağı şunlardır:

• Revizyonlar (Revisions) — Bir yazıyı her düzenlediğinizde, WordPress yazının tam bir kopyasını wp_posts tablosunda saklar. Bir yazıda on düzenleme, her biri tam metin içeren on ekstra satır demektir.
• Geçici Veriler (Transients) — Eklentilerin ve WordPress'in wp_options tablosunda tuttuğu geçici önbellek. Sorun şu ki, birçok geçici veri süresi dolduktan sonra silinmez ve sonsuza kadar kalır.
• Yetim Meta Kayıtları (Orphaned Meta) — Bir yazıyı sildiğinizde, o yazıya ait satırlar wp_postmeta tablosunda kalır. Hiçbir sorgu bunlara erişemez, ancak yer kaplarlar.
• Silinen Eklentilerden Kalan Tablolar — Eklentiyi silersiniz, ancak tabloları veritabanında kalır. Bu tablolardan bazıları onlarca megabayt boyutunda olabilir.

Şimdi her birini nasıl temizleyeceğimize bakalım.

Revizyonları tek bir sorguyla silin

Başlamak için en basit ve en güvenli yer revizyonlardır. Bu sorgu, her yazının son sürümü dışındaki tüm revizyonları siler:

DELETE FROM wp_posts
WHERE post_type = 'revision'
AND ID NOT IN (
    SELECT MAX(ID) FROM wp_posts
    WHERE post_type = 'revision'
    GROUP BY post_parent
);

Bundan sonra revizyonların hiç oluşturulmamasını istiyorsanız, wp-config.php dosyanıza şu satırı ekleyin:

define('WP_POST_REVISIONS', 2);

Bu ayar, WordPress'i her yazının yalnızca son 2 sürümünü tutmaya zorlar. Sıfır sayısı tamamen devre dışı bırakmak anlamına gelir, ancak benim önerim 2 sayısıdır. Çünkü yanlışlıkla bir metni siler ve geri getirmek isterseniz, önceki bir sürümünüz olur.

Süresi dolmuş geçici verileri temizleyin

Geçici veriler wp_options tablosunda _transient_... ve _transient_timeout_... gibi adlarla saklanır. Aşağıdaki sorgu, süresi dolmuş tüm geçici verileri siler:

DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP();

Bundan sonra, karşılık gelen satırları da silmelisiniz. Bu ikinci sorguyu çalıştırın:

DELETE o1 FROM wp_options o1
LEFT JOIN wp_options o2
ON o2.option_name = CONCAT('_transient_', SUBSTRING(o1.option_name, 20))
WHERE o1.option_name LIKE '_transient_%'
AND o2.option_id IS NULL;

İşte burada hata yapıyorlar: Birçok kişi ilk sorguyu çalıştırır ve işin bittiğini düşünür. Ancak geçici verinin ana satırları (timeout olmadan) hâlâ tabloda kalır. Yalnızca ilk sorguyu çalıştırırsanız, boyut neredeyse yarıya iner ve birkaç hafta sonra aynı duruma geri dönersiniz. Her iki sorguyu da arka arkaya çalıştırın.

Yetim meta kayıtlarını bulun ve silin

Yetim meta kayıtları, artık var olmayan bir yazıya işaret eden wp_postmeta satırlarıdır. Bu sorgu onları siler:

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

Aynı deseni wp_commentmeta için de tekrarlayabilirsiniz, eğer o tablonun da büyüdüğünü görürseniz. Sadece tablo adını değiştirin.

Silinen eklentilerden kalan tabloları tanımlayın

Bu bölüm en hassas iştir. Bazı eklentiler silinirken tablolarını temizler, bazıları temizlemez. Fazladan tabloları bulmak için önce WordPress'in hangi ön eki kullandığına bakın. Genellikle wp_ olur, ancak bazı sitelerin özel bir ön eki vardır. phpMyAdmin'de şu sorguyu çalıştırın:

SHOW TABLES LIKE 'wp\_%';

Şimdi standart WordPress tablolarının listesini bir kenara koyun: wp_posts, wp_postmeta, wp_options, wp_users, wp_usermeta, wp_terms, wp_termmeta, wp_term_taxonomy, wp_term_relationships, wp_comments, wp_commentmeta, wp_links ve WordPress'iniz çoklu site ise çoklu site tabloları. Gördüğünüz diğer her tablo ya bir eklentiden ya da özel bir betikten gelir.

Herhangi bir tabloyu silmeden önce, tablo adıyla basit bir Google araması yapın ve hangi eklentiye ait olduğunu görün. Eklentiyi gerçekten sildiyseniz ve verilerine ihtiyacınız yoksa, DROP TABLE komutunu çalıştırın. Ancak şüpheniz varsa, önce bir yedek alın. Yanlış tabloyu silmek, geri dönüşü olmayabilecek verileri kaybetmek demektir.

Her şeyden önce yedek alın, her şeyden sonra optimize edin

Bu kuralı çiğnemeyin: Herhangi bir DELETE sorgusu çalıştırmadan önce veritabanının tam bir yedeğini alın. Yalnızca temizlemek istediğiniz tablonun değil, tüm veritabanının. phpMyAdmin'de Export seçeneğine tıklayın ve Quick yöntemini seçin. İki dakikanızı alır ve bir şey ters giderse hayat kurtarır.

Temizlikten sonra, boşalan alanın gerçekten sunucuya dönmesi için tabloları optimize edin. phpMyAdmin'de veritabanı adına tıklayın, tüm tabloları seçin ve açılır menüden Optimize Table seçeneğini seçin. Bu, dizinleri yeniden oluşturur ve çok sayıda satır silindikten sonra parçalanan tabloları düzenler.

Önemli not: Siteniz paylaşımlı hosting'deyse ve veritabanı büyükse, DELETE sorgularını çalıştırmak 504 Gateway Timeout hatasıyla karşılaşabilir. Bu durumda sorguyu LIMIT ile sınırlayın ve birkaç kez çalıştırın:

DELETE FROM wp_posts
WHERE post_type = 'revision'
LIMIT 1000;

Bu sorguyu 0 rows affected diyene kadar çalıştırın. Evet, sıkıcıdır. Ancak sunucuyu çökertme riski taşıyan ağır bir sorgudan daha güvenlidir.

İşte burada hata yapıyorlar: Veritabanı temizleme eklentisi kuruyorlar ve unutuyorlar

Bu kalıbı defalarca gördüm: Site yöneticisi bir veritabanı temizleme eklentisi kurar, bir kez çalıştırır, sonucu görür ve memnun olur. Üç ay sonra veritabanı yine aynı boyuta ulaşır. Çünkü temizleme eklentileri yalnızca çalıştırıldıklarında işe yarar. Onlar için bir Cron Job ayarlamazsanız, yalnızca bir kez çalışırlar ve biter.

Ayrıca, kurduğunuz her eklenti, veritabanına kendi ağırlığını ekler. 5 basit sorguyla çözülebilecek bir sorunu temizlemek için kalıcı bir eklenti kurmak, ayda yalnızca bir gün çalışan tam zamanlı bir işçiyi odayı temizlemek için işe almak gibidir.

Benim yöntemim şu: Yukarıdaki sorgularla basit bir betik yazın ve sunucuda aylık cron job ile çalıştırın. Linux hosting kullanıyorsanız, crontab kullanabilirsiniz. Bu, eklentiye ihtiyaç duymadan otomatik olarak yapılır ve siz unutursunuz.

Temizlikten sonra neyi kurduğunuza dikkat edin

Veritabanı temizlendi ve boyutu 400 MB'tan 80 MB'a düştü. Peki şimdi ne olacak? Kullanım alışkanlıklarınız değişmezse, altı ay sonra yine aynı duruma gelirsiniz. Birkaç basit alışkanlığı ciddiye alın:

• Deneme amaçlı kurduğunuz ve kullanmadığınız bir eklentiyi aynı gün silin. Haftaya değil, aynı gün.
• Bir eklentiyi silmeden önce, dokümantasyonunda tablolarını temizleyip temizlemediğini kontrol edin. Temizlemiyorsa, sildikten sonra tabloları yukarıda anlattığım yöntemle elle silin.
• Birden fazla yazarı olan siteler için, revizyon sınırını mutlaka wp-config.php dosyasında ayarlayın. Yazarlar bir yazıyı on kez düzenleme alışkanlığına sahiptir.

Sitenizde yüksek miktarda görsel ve medya dosyası varsa, yavaşlığın büyük bir kısmı veritabanından değil, uygun önbellek eksikliğinden kaynaklanıyor olabilir. Bu durumda önce site hız testi yapın ve sorunun gerçekte nerede olduğunu görün. Veritabanı temizliği optimizasyon araçlarından yalnızca biridir, hepsi değildir.

Sıkça Sorulan Sorular

Revizyonları silmek yazılarıma zarar verir mi?

Hayır. Revizyonlar yazının önceki sürümleridir ve silinmeleri yayınlanan son sürümü hiçbir şekilde etkilemez. Kaybedeceğiniz tek şey, daha eski düzenleme sürümlerine geri dönme imkânıdır. Düzenleme geçmişine ihtiyacınız varsa, sınırı sıfır değil 2 veya 3 olarak ayarlayın.

WordPress veritabanımın temizliğe ihtiyacı olduğunu nasıl anlarım?

phpMyAdmin'de veritabanı adına tıklayın ve toplam boyutu görün. Veritabanı boyutu, sitenin toplam içerik boyutundan (görseller ve dosyalar hariç) büyükse veya wp_options satır sayısı birkaç on bini aştıysa, temizlik zamanı gelmiştir. 500 yazılı normal bir sitenin veritabanı 50 MB'tan büyük olmamalıdır.

Veritabanı temizliği WordPress ayarlarımın kaybolmasına neden olur mu?

Hayır, yalnızca revizyonları, süresi dolmuş geçici verileri ve yetim meta kayıtlarını silerseniz. WordPress'in ana ayarları wp_options tablosunda siteurl veya blogname gibi belirli adlarla saklanır ve yukarıdaki sorgular bunlara dokunmaz. Yalnızca wp_options tablosunun tamamını boşaltacak bir sorgu yazmamaya dikkat edin.

Veritabanı temizliğinden sonra site hızlanır mı?

Duruma bağlı. Sitenin yavaşlığı ağır veritabanından kaynaklanıyorsa, evet, belirgin bir fark olacaktır. Ancak sorun önbellek eksikliği, ağır görseller veya zayıf hosting ise, veritabanı temizliği mucize yaratmaz. Doğru teşhis için önce yavaşlığın kaynağını bulun. Veritabanı, sınırlı kaynaklara sahip bir hosting'de çalışıyorsa ve boyutu büyükse, belki de daha yüksek kaynaklı WordPress hosting düşünmenin zamanı gelmiştir.