WordPress Veritabanı Optimizasyonu Nasıl Yapılır?

WordPress sitesi ilk kurulduğunda hızlıdır. Aylar geçtikçe eklentiler, taslaklar, silinen yorumlar ve sürekli kaydedilen yazı revizyonları veritabanının içinde birikir. Ziyaretçi bunu görmez ama sunucu her istekte bu yükü taşır. Yavaşlamanın nedeni çoğu zaman temanız ya da görselleriniz değil, arka planda sessizce şişmiş bir MySQL veritabanıdır.

Bu yazıda WordPress veritabanının nasıl çalıştığını, nerelerde tıkandığını ve onu güvenli biçimde nasıl optimize edeceğinizi anlatıyoruz. Hem eklenti kullanmak isteyenler hem de WP-CLI ve doğrudan SQL ile çalışmayı tercih eden ileri seviye kullanıcılar için yöntemleri ayrı ayrı ele alacağız. Amacımız körlemesine “her şeyi temizle” demek değil; gerçekten işe yarayan hamleleri, zaman kaybettiren mitlerden ayırmak.

WordPress veritabanı neden zamanla yavaşlar?

WordPress verilerinin büyük kısmını bir MySQL (ya da MariaDB) veritabanında saklar. Yazılarınız wp_posts tablosunda, ayarlarınız wp_options tablosunda, yorumlar, kullanıcılar ve eklenti verileri kendi tablolarında durur. Sorun verinin varlığı değil, gereksiz verinin birikmesi ve tabloların zamanla parçalanmasıdır.

En sık karşılaşılan şişme kaynakları şunlardır:

• Yazı revizyonları: Bir yazıyı her kaydettiğinizde WordPress eski halini revizyon olarak saklar. İçerik yoğun bir sitede tek yazının 40-50 revizyonu olabilir; binlerce satır birikir.
• Süresi dolmuş transient’ler: Transient, WordPress’in geçici önbellek mekanizmasıdır. Süresi dolduğunda otomatik silinmezler ve wp_options tablosunda birikirler.
• Otomatik taslaklar ve çöp kutusu: Silinen yazılar ve yorumlar 30 gün çöpte bekler; spam yorumlar da tabloda yer kaplar.
• Kaldırılan eklentilerin artıkları: Bir eklentiyi silmek onun veritabanı tablolarını ya da ayar satırlarını çoğu zaman silmez. Yıllar içinde onlarca “yetim” tablo birikir.
• Şişmiş wp_options ve autoload: Aşağıda ayrı bir başlıkla ele alacağımız, en kritik ve en çok gözden kaçan konu.

Optimizasyona başlamadan önce: mutlaka yedek alın

Veritabanı optimizasyonu geri alınamayan silme işlemleri içerir. Bir sorgu yanlış yazılırsa ya da bir eklenti fazla agresif temizlik yaparsa içeriğinizi kaybedebilirsiniz. Bu yüzden ilk kural değişmez: işleme başlamadan önce tam bir veritabanı yedeği alın.

phpMyAdmin üzerinden “Dışa Aktar” ile ya da WP-CLI ile tek komutta yedek alabilirsiniz:

• wp db export yedek-tarih.sql komutu tüm veritabanını tek SQL dosyasına çıkarır.
• Sunucunuzda otomatik günlük yedekleme varsa yine de manuel bir yedekle işi sağlama alın.

Alastyr’da barındırılan tüm hesaplarda günlük yedekleme standart olarak çalışır; yani agresif bir temizlik sonrası bir sorun yaşarsanız, panelden önceki güne dönmek birkaç dakikanızı alır. Yine de kritik bir işlemden hemen önce elle bir yedek almak en güvenli alışkanlıktır.

wp_options ve autoload: en önemli optimizasyon

Çoğu rehber revizyon temizliğiyle başlar ama gerçek performans farkını yaratan yer genellikle wp_options tablosu ve onun autoload sütunudur. Autoload değeri “yes” olan satırlar, sitenizin her sayfa isteğinde otomatik olarak belleğe yüklenir. Site URL’niz, aktif temanız, eklenti ayarlarınız burada tutulur ve bu doğrudur.

Sorun, bazı eklentilerin devasa veri bloklarını (önbellek, log, geçici veri) autoload olarak işaretlemesidir. Kaldırdığınız bir eklenti bile burada yüzlerce KB veri bırakmış olabilir. Toplam autoload boyutunun 800 KB altında kalması önerilir; 1 MB üzeri ciddi bir kırmızı bayraktır.

Mevcut autoload boyutunuzu şu SQL sorgusuyla ölçebilirsiniz:

SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS ‘Autoload MB’ FROM wp_options WHERE autoload = ‘yes’;

Hangi satırların en çok yer kapladığını görmek için:

SELECT option_name, LENGTH(option_value) AS boyut FROM wp_options WHERE autoload = ‘yes’ ORDER BY boyut DESC LIMIT 20;

Bu listede tanıdık olmayan, sildiğiniz bir eklentiye ait büyük bir satır görürseniz, o satırın autoload değerini “no” yapabilir ya da satırı tamamen silebilirsiniz. Ancak burada dikkatli olun: aktif bir eklentiye ait bir ayarı yanlışlıkla kapatmak o eklentiyi bozabilir. Emin olmadığınız satırı önce autoload=’no’ yapıp siteyi test etmek, silmekten daha güvenlidir.

Transient’leri ve revizyonları temizlemek

Autoload’u ele aldıktan sonra sıradaki büyük temizlik alanı transient’ler ve revizyonlardır. Süresi dolmuş transient’ler tek başına performans katili olabilir; wp_options tablosunda 10.000 süresi dolmuş transient varsa, bunlar her istekte gereksiz yere yüklenen 10.000 satır demektir.

Transient temizliği

WP-CLI kullanıyorsanız süresi dolmuş transient’leri tek komutla silebilirsiniz:

• wp transient delete –expired yalnızca süresi dolmuş olanları temizler (güvenli seçenek).
• wp transient delete –all tüm transient’leri siler; önbellek yeniden oluşacağından geçici bir yavaşlama normaldir.

Revizyonları sınırlamak

Revizyonlar içerik yazarken faydalıdır ama sınırsız birikmelerine gerek yoktur. En temiz çözüm, gelecekteki revizyon sayısını wp-config.php dosyasından sınırlamaktır:

define(‘WP_POST_REVISIONS’, 5);

Bu satır her yazı için en fazla 5 revizyon tutulmasını sağlar. Mevcut eski revizyonları temizlemek içinse WP-CLI ile yazı türü “revision” olan kayıtları silebilir ya da bir bakım eklentisi kullanabilirsiniz. Revizyonları tamamen kapatmak (değeri 0 ya da false yapmak) çoğu editör için önerilmez; içerik kaybında geri dönüş imkanınız olmaz.

Tabloları optimize etmek: OPTIMIZE TABLE ve InnoDB gerçeği

Satırları sildikten sonra tablolarda “overhead” denen boş, parçalanmış alanlar kalır. Bunu toparlamak için OPTIMIZE TABLE komutu kullanılır. Ancak burada yaygın bir yanlış anlama var ve 2026 itibarıyla durumu netleştirmek gerekiyor.

Modern WordPress kurulumları neredeyse her zaman InnoDB depolama motorunu kullanır. InnoDB, aynı anda birçok işlemi güvenle yürütmek için tasarlanmıştır ve yalnızca yazılan satırı kilitler. Eski MyISAM motorunda OPTIMIZE TABLE tabloyu fiziksel olarak yeniden düzenlerdi. InnoDB’de ise bu komut tabloyu yeniden oluşturur ve indeksleri günceller; işlem başarılı olsa bile bir uyarı mesajı görebilirsiniz. Bu uyarı beklenen bir davranıştır, hata değildir.

Pratikte yapmanız gerekenler:

Yöntem	Komut / İşlem	Ne zaman uygun?
WP-CLI	wp db optimize	Tüm tabloları tek komutta optimize etmek için en pratik yol
phpMyAdmin	Tabloları seç → “Tabloyu optimize et”	Panelden görsel olarak, seçili tablolarda çalışmak isteyenler
Doğrudan SQL	OPTIMIZE TABLE wp_options;	Belirli, şişmiş tek bir tabloyu hedeflemek için

Not: OPTIMIZE TABLE tabloyu geçici olarak kilitleyebilir, bu yüzden yoğun trafik saatlerinde değil, sakin bir zaman diliminde çalıştırın.

Yavaş sorguları bulmak ve indeks eklemek

Temizlik ve optimizasyon çoğu sitede yeter. Ama trafik yüksekse ya da özel sorgular yapan eklentiler varsa, asıl darboğaz belirli yavaş sorgular olabilir. Bu ileri seviye adımı “her şeyi hızlandırmak” için değil, ölçüp bulduğunuz gerçek bir sorunu çözmek için yapın.

• Query Monitor eklentisi: Hangi sorgunun ne kadar sürdüğünü ve hangi eklentiden geldiğini gösterir.
• Yavaş sorgu günlüğü (slow query log): Sunucu tarafında belirli süreyi aşan sorguları kaydeder.
• EXPLAIN: Yavaş sorgunun önüne EXPLAIN yazarak MySQL’in o sorguyu nasıl çalıştırdığını, indeks kullanıp kullanmadığını görürsünüz.

Bir sorgu WHERE ya da JOIN koşulunda indekssiz bir sütunu tarıyorsa, o sütuna indeks eklemek sorguyu on kat hızlandırabilir. Ancak gereksiz indeks eklemek de yazma işlemlerini yavaşlatır; bu yüzden indeksi ölçüme dayanarak, seçerek ekleyin.

Sunucu tarafı: buffer pool, önbellek ve barındırma katmanı

Veritabanı optimizasyonu yalnızca WordPress içindeki temizlikten ibaret değildir. Performansın büyük kısmı, veritabanının çalıştığı sunucu ortamında belirlenir. Paylaşımlı bir ortamda MySQL ayarlarını siz değiştiremezsiniz; işte bu noktada barındırma altyapısının kalitesi doğrudan sonucunuza yansır.

İyi yapılandırılmış bir ortamda şunlar önemlidir:

• innodb_buffer_pool_size: InnoDB’nin veriyi bellekte tuttuğu alan; genelde sunucu RAM’inin yüzde 60-80’i olacak şekilde ayarlanır. Diskten okuma yerine bellekten okuma, en büyük hız kazancıdır.
• Nesne önbelleği (object cache): Redis gibi bir bellek içi önbellek, tekrar eden veritabanı sorgularını RAM’den karşılayarak MySQL yükünü ciddi biçimde azaltır.
• Sunucu düzeyinde sayfa önbelleği: LiteSpeed ve LSCache gibi teknolojiler, dinamik sayfaları önbelleğe alarak veritabanına hiç dokunmadan yanıt verir.
• PHP sürümü: Güncel bir PHP sürümü, veritabanı sonuçlarının işlenmesini de hızlandırır.

Alastyr’ın WordPress hosting paketleri LiteSpeed web sunucusu ve LSCache ile çalışır; CloudLinux ile her hesap kendi kaynak sınırında izole edilir, yani yan komşunuzun yoğun bir sorgusu sizin veritabanınızı yavaşlatmaz. PHP sürüm seçici sayesinde WordPress’inizi güncel bir sürümle çalıştırabilirsiniz. İhtiyacınız kaynak açısından paylaşımlı planı aşıyorsa bulut sunucu ya da VPS ile MySQL ayarlarını doğrudan yönetebileceğiniz kök erişimli bir ortama geçebilirsiniz.

Düzenli bakım: bir kereye mahsus değil, alışkanlık

Veritabanı optimizasyonu tek seferlik bir iş değildir; site yaşadıkça birikinti tekrar oluşur. En sağlıklı yaklaşım, temizliği otomatikleştirmektir. WP-CLI komutlarını sunucu cron’una bağlayarak elle uğraşmadan düzenli bakım kurabilirsiniz.

Görev	Önerilen sıklık	Yaklaşım
Süresi dolmuş transient temizliği	Haftalık	wp transient delete –expired (cron)
Revizyon ve çöp temizliği	Aylık	Bakım eklentisi ya da WP-CLI
Tablo optimizasyonu (wp db optimize)	Aylık	Sakin saatte, cron ile
wp_options / autoload denetimi	Üç ayda bir	SQL ile elle inceleme
Tam veritabanı yedeği	Günlük	Otomatik (barındırma tarafında)

WP-Optimize gibi eklentiler bu görevlerin çoğunu panelden zamanlanmış olarak yapabilir ve eklenti kullanmak istemeyenler için WP-CLI kombinasyonu (örneğin haftalık wp db optimize && wp transient delete –expired) aynı işi görür.

Kaçınmanız gereken hatalar

• Yedeksiz temizlik: En sık yapılan ve en pahalıya patlayan hata. Her zaman önce yedek.
• Bilinmeyen tabloyu silmek: Aktif bir eklentiye ait tabloyu “yetim” sanıp silmek siteyi bozabilir. Emin olmadan silmeyin.
• Aşırı indeksleme: Her sütuna indeks eklemek yazma performansını düşürür; sadece ölçtüğünüz yavaş sorgular için indeks ekleyin.
• Revizyonları tamamen kapatmak: Sınırlamak mantıklı, tamamen kapatmak içerik güvenliğinizi riske atar.
• Yoğun saatte OPTIMIZE: Tablo kilitlenebilir; sakin bir zaman dilimi seçin.

Sıkça Sorulan Sorular

WordPress veritabanı optimizasyonu ne sıklıkla yapılmalı?

Transient temizliğini haftalık, revizyon ve tablo optimizasyonunu aylık, autoload denetimini ise üç ayda bir yapmak dengeli bir programdır. WP-CLI ve cron ile bu işlemleri otomatikleştirerek elle uğraşmadan düzenli bakım sağlayabilirsiniz.

Optimizasyon işlemi sitemdeki içeriği siler mi?

Doğru yapıldığında yayınlanmış içeriğiniz silinmez; yalnızca revizyon, süresi dolmuş transient, çöp yorum ve otomatik taslak gibi gereksiz veriler temizlenir. Yine de her işlemden önce tam bir veritabanı yedeği almak, olası bir hatada içeriğinizi güvence altına alır.

OPTIMIZE TABLE InnoDB tablolarında işe yarar mı?

InnoDB’de OPTIMIZE TABLE komutu tabloyu yeniden oluşturur ve indeksleri günceller. İşlem başarılı olsa bile bir uyarı mesajı görebilirsiniz; bu beklenen bir davranıştır, hata değildir. Modern kurulumlarda genellikle wp db optimize komutunu kullanmak en pratik yoldur.

Autoload boyutu ne kadar olmalı?

Toplam autoload verinizin 800 KB altında kalması önerilir. 1 MB üzeri değerler, her sayfa isteğinde gereksiz yükleme anlamına gelir ve performansı belirgin biçimde düşürür. SQL ile en büyük autoload satırlarını bulup gereksizleri kapatmak, çoğu zaman en büyük hız kazancını sağlar.

Revizyonları wp-config.php ile nasıl sınırlarım?

wp-config.php dosyasına define(‘WP_POST_REVISIONS’, 5); satırını eklemek her yazı için en fazla 5 revizyon tutulmasını sağlar. Bu satırı “define” bloklarından önce eklemeye dikkat edin. Revizyonları tamamen kapatmak yerine sınırlamak, içerik güvenliği açısından daha doğrudur.

Eklenti kullanmadan veritabanını optimize edebilir miyim?

Evet. WP-CLI ile wp db optimize, wp transient delete –expired gibi komutları ya da phpMyAdmin üzerinden doğrudan SQL ve “Tabloyu optimize et” seçeneğini kullanabilirsiniz. Eklentiler işi kolaylaştırır ama zorunlu değildir; ileri seviye kullanıcılar için komut satırı daha esnek ve hızlıdır.

Paylaşımlı hostingte MySQL ayarlarını değiştirebilir miyim?

Paylaşımlı ortamda innodb_buffer_pool_size gibi sunucu düzeyi ayarlar barındırma sağlayıcısı tarafından yönetilir. Bu ayarların kalitesi doğrudan sitenizin hızını etkiler. Tam kontrol istiyorsanız kök erişimli bir VPS ya da bulut sunucuya geçerek MySQL yapılandırmasını kendiniz yönetebilirsiniz.

Redis nesne önbelleği veritabanı yükünü nasıl azaltır?

Redis, tekrar eden veritabanı sorgularının sonucunu RAM’de tutar; aynı sorgu tekrar geldiğinde MySQL’e hiç gitmeden bellekten yanıt verilir. Bu, özellikle dinamik ve yoğun trafikli sitelerde veritabanı yükünü ciddi biçimde azaltır ve sayfa yanıt sürelerini kısaltır.

Kaldırdığım eklentilerin veritabanı artıkları tehlikeli mi?

Doğrudan tehlikeli olmasalar da wp_options tablosunu şişirir ve autoload yükünü artırabilirler. Silinmiş bir eklentiye ait büyük autoload satırlarını SQL ile bulup temizlemek performansı iyileştirir. Emin olmadığınız satırları silmeden önce autoload değerini “no” yapıp siteyi test etmek daha güvenlidir.