Kısa cevap: WordPress yavaşsa suçlu çoğu zaman PHP değil, veritabanıdır. MariaDB/MySQL tuning’inin kalbi tek ayardır: innodb_buffer_pool_size — tablo ve indeksleri RAM’de tutar, disk okumasını keser. Yanına slow query log ile darboğaz sorgularını bul, gereksiz query cache‘i kapat, ve WordPress’in kendi şişkinliğini (autoload, revizyon, transient) temizle. Altın kural yine aynı: mysqltuner ile ölç, sonra ayarla.
Bir WordPress sayfası açılırken arka planda onlarca veritabanı sorgusu çalışır. Site büyüdükçe bu sorgular birikir ve TTFB’yi şişirir. Redis object cache bunun bir kısmını çözer ama asıl temel, veritabanı sunucusunun kendisinin doğru ayarlanmasıdır. Performans yazımızda PHP katmanını ele aldık; burada eksik üçüncü katmanı tamamlıyoruz: MariaDB/MySQL.
Tek en önemli ayar: InnoDB buffer pool
WordPress tabloları InnoDB motorunu kullanır. innodb_buffer_pool_size, InnoDB’nin veri ve indeksleri önbelleğe aldığı RAM havuzudur. Yeterince büyükse, sık erişilen tüm veri bellekten gelir; disk neredeyse devre dışı kalır. Bu yüzden en yüksek getirili tek ayardır.
[mysqld]
# Adanmış DB sunucusunda RAM'in ~%70'i; web+DB aynı sunucudaysa ~%25-40
innodb_buffer_pool_size = 2G
innodb_buffer_pool_instances = 1 # her ~1GB için +1 (büyük havuzlarda)
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2 # performans/dayanıklılık dengesi
innodb_flush_method = O_DIRECT“buffer pool’a RAM’in %80’ini ver” tavsiyesi adanmış bir veritabanı sunucusu içindir. Ama tipik bir Virtualmin kurulumunda WordPress, PHP-FPM, Nginx ve MariaDB aynı sunucudadır. Buraya %80 verirseniz PHP ve web sunucusuna yer kalmaz, sistem takas (swap) yapıp yavaşlar. Paylaşımlı kutuda buffer pool’u ~%25-40 ile başlatıp ölçerek artırın.
Query cache: kapatın (sürpriz ama doğru)
Eski rehberler “query cache aç” der; bu artık yanlış bir tavsiyedir. MySQL 8.0, query cache’i tamamen kaldırdı çünkü çok çekirdekli sistemlerde ciddi ölçeklenme sorunlarına yol açıyordu. MariaDB’de hâlâ var ama çoğu üretim WordPress’inde kapalı tutulması önerilir — her yazma işleminde önbelleği geçersiz kılma yükü, faydasından büyük olur.
query_cache_type = 0
query_cache_size = 0Darboğazı bul: slow query log
Körlemesine ayar yapmak yerine, gerçekten yavaş olan sorguları ölçün. Slow query log, belirlediğiniz süreden uzun süren sorguları bir dosyaya yazar:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 # 1 saniyeden uzun sorgular
log_queries_not_using_indexes = 1
# Sonra en sık/yavaş sorguları özetle:
mysqldumpslow -s t /var/log/mysql/slow.log | head -20Genellikle birkaç eklenti sorgusu ya da indekssiz bir wp_postmeta taraması tüm yükü oluşturur. Onları bulmadan ayar yapmak, karanlıkta nişan almaktır.
Ölçüm aracı: mysqltuner
Hangi ayarı ne yapacağınızı tahmin etmeyin. mysqltuner, mevcut yükünüzü analiz edip somut öneriler verir (buffer pool sağlığı, fragmente tablolar, bağlantı kullanımı):
curl -L https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl -o mysqltuner.pl
perl mysqltuner.pl
# Önemli: önerileri uygulamadan önce sunucunun en az birkaç saat
# gerçek trafik altında çalışmış olması gerekir (yoksa veriler yanıltıcı).WordPress’in kendi şişkinliğini temizle
Bazen sorun sunucu ayarı değil, veritabanının kendisidir. WordPress zamanla şişer ve bu doğrudan yavaşlık üretir:
| Şişkinlik kaynağı | Etki / çözüm |
|---|---|
wp_options autoload |
Her istekte yüklenir; 1MB’ı aşması ciddi yavaşlık — şişkin autoload satırlarını temizle |
| Yazı revizyonları | Sınırsız birikir; WP_POST_REVISIONS ile sınırla |
| Süresi geçmiş transient | Birikmiş geçici veriler; düzenli temizle |
| Eksik indeks | Özellikle ağır wp_postmeta sorgularında indeks ekle |
Ölçmeden ayar yapma
Buradaki her değer bir başlangıç noktasıdır. Doğru döngü: bir ayarı değiştir, gerçek trafik altında TTFB ve slow query log’u izle, sonra ilerle. innodb_buffer_pool_size‘ı RAM’i aşacak kadar büyütmek swap’a, query cache’i açık bırakmak gereksiz yüke yol açar. Veritabanı tuning’i bir kerelik iş değil, ölçüm alışkanlığıdır.
DKS pratikte ne yapıyor?
Bir siteyi hızlandırırken veritabanını ölçerek ele alıyoruz: önce slow query log + mysqltuner ile darboğazı buluyor, buffer pool’u sunucunun gerçek RAM dağılımına göre (web+DB aynı kutuda mı, adanmış mı) ayarlıyor, query cache’i kapatıyor ve WordPress’in autoload/revizyon şişkinliğini temizliyoruz. Performans optimizasyonu tarafında yaptığımız iş tam da bu katmanlı ölçüm-tuning döngüsü. Çünkü en hızlı veritabanı, en çok RAM verilen değil; darboğazı doğru teşhis edilendir.
Sıkça sorulan sorular
innodb_buffer_pool_size ne olmalı?
Adanmış bir veritabanı sunucusunda RAM’in yaklaşık %70-80’i idealdir. Ancak WordPress, PHP ve web sunucusu aynı makinedeyse bu kadar yüksek vermek sistemi takasa sokup yavaşlatır; paylaşımlı kutuda ~%25-40 ile başlayıp ölçerek artırın. En önemli ayar budur çünkü veriyi diskten değil RAM’den okutur.
Query cache’i açmalı mıyım?
Hayır. MySQL 8.0 query cache’i ölçeklenme sorunları nedeniyle tamamen kaldırdı; MariaDB’de hâlâ var ama çoğu üretim WordPress’inde kapalı tutulması önerilir. Her yazma işleminde önbelleği geçersiz kılma yükü faydasından büyüktür.
WordPress veritabanım neden şişiyor?
En sık nedenler: wp_options tablosundaki büyük autoload verisi (her istekte yüklenir), sınırsız biriken yazı revizyonları ve süresi geçmiş transient kayıtları. Bunları temizlemek ve indeksleri düzeltmek, bazen sunucu ayarından daha çok fark yaratır.
Hangi ayarı değiştireceğimi nasıl bilirim?
Tahmin etmeyin, ölçün. mysqltuner aracını (gerçek trafik altında çalıştıktan sonra) kullanın ve slow query log ile asıl yavaş sorguları bulun. Ayarları tek tek değiştirip TTFB ve log’u izleyerek ilerleyin.
Redis object cache veritabanı tuning’in yerini tutar mı?
Hayır, birbirini tamamlar. Redis tekrar eden sorgu sonuçlarını RAM’de tutar; veritabanı tuning ise sorguların kendisini hızlandırır. İkisi birlikte en iyi sonucu verir; ama önce veritabanı sağlığı, sonra Redis.
WordPress siteniz yavaşsa suçlu çoğu zaman veritabanıdır. Bir performans denetimi isteyin; slow query log ve mysqltuner ile gerçek darboğazı bulup somut bir ayar planı çıkaralım.
