WordPress Veritabanı Optimizasyonu: Autoload ve Tablolar

WordPress Veritabanında Autoload ve Büyük Tablolar

WordPress sitelerde veritabanı performansı konuşulunca çoğu kişi doğrudan sorgulardan, indekslerden veya MySQL ayarlarından bahseder. Ancak incelenmesi gereken alanlardan biri de büyüyen wp_options tablosudur. Özellikle WooCommerce, çok sayıda eklenti veya sık tema değişikliği kullanılan sitelerde gereksiz kayıtlar ve büyük autoload verileri birikebilir. Bu durum artan TTFB ve kaynak kullanımına katkıda bulunabilir; yavaşlık veya beyaz ekran tek başına bu tablonun sorunlu olduğunu göstermez.

Bu rehberde WordPress veritabanı optimizasyonunu iki düzeyde ele alıyoruz: wp_options ve autoload yükü; ardından wp_postmeta, revizyonlar, yorumlar ve eklenti logları gibi büyük tablolar. Önce verinin boyutunu, kullanımını ve sorgu maliyetini ölçüyor; sonra doğrulanmış silme adaylarını, saklama kurallarını ve tablo bakımını değerlendiriyoruz. Yedek ve staging kontrollerini, büyük canlı tablolar için ayrıca tasarlanması gereken partili yürütme planından ayırıyoruz. Amaç, gerekli veriyi koruyarak darboğaza yönelik ölçülebilir bir iyileştirme sağlamaktır.

wp_options Tablosunu Gerçekten Tanımak

Temel Yapı: Hangi Alan Ne İşe Yarar?

Varsayılan bir WordPress kurulumunda wp_options tablosu (önek değiştirdiyseniz farklı isimdedir) şu kritik alanları içerir:

• option_id: Her kayıt için benzersiz kimlik (primary key).
• option_name: Ayarın adı. Örnek: siteurl, home, blogdescription, woocommerce_version, wc_cache_excluded.
• option_value: Ayarın gerçek değeri. Düz metin, dizi (serialize edilmiş), JSON vb olabilir.
• autoload: Ayarın otomatik yüklenme davranışını belirleyen alan.

Uygulama tarafında pek çok eklenti ve tema, konfigürasyon verilerini, geçici cache verilerini ve hatta log benzeri verileri bile wp_options içinde saklar. Bu da zaman içinde tablonun hem satır sayısı hem de tek tek option_value boyutu açısından büyümesine neden olur.

Autoload Mantığı Nasıl Çalışır?

WordPress’in çalıştığı isteklerde, belli ayarları tek tek sorgulamak yerine birlikte yüklemek için autoload alanı kullanılır. Aşağıda yes / no değerleri üzerinden basitleştirilmiş bir örnek verilmiştir:

• autoload = yes olan kayıtlar birlikte yüklenir; kalıcı nesne önbelleğinde kullanılabilir veri varsa her istekte yeniden SELECT çalıştırılması gerekmez.
• autoload = no olan kayıtlar ihtiyaç duyulduğunda alınır; önbellekten karşılanan erişim için ayrıca veritabanı sorgusu gerekmez.

Autoload ile yüklenen verilerin toplam boyutu büyüdükçe bellek ve veri işleme yükü artabilir. Özellikle yüzlerce kilobayt veya megabayta ulaşan serialize edilmiş dizilerin TTFB üzerindeki etkisini ölçmek gerekir; veri boyutu tek başına gecikmenin nedenini veya büyüklüğünü belirlemez.

Hangi Veriler wp_options İçine Yazılır?

Genel olarak şunları wp_options içinde görürsünüz:

• Çekirdek WordPress ayarları (siteurl, home, permalink_structure vb).
• Tema ayarları, widget konfigürasyonları.
• Eklenti lisans anahtarları, API anahtarları, genel konfigürasyonlar.
• Geçici veriler (transient), cache edilmiş sonuçlar.
• Bazen hatalı yazılmış eklentiler nedeniyle log, istatistik, büyük liste verileri, queue benzeri yapılar.

Büyük veri setlerinde erişim biçimine göre ayrı özel tablolar, yeniden üretilebilir önbellek verileri içinse Redis gibi harici cache sistemleri değerlendirilebilir. Kalıcı verinin saklanması ile önbellekleme farklı ihtiyaçlardır; wp_options içindeki her büyük kayıt da gereksiz değildir.

Şişmiş wp_options Belirtileri ve Teşhis Yöntemleri

Şişmiş wp_options Tablosunun Tipik Belirtileri

Aşağıdaki belirtiler wp_options tablosunu incelemek için gerekçe olabilir; ancak tek başlarına sorunun bu tablodan kaynaklandığını kanıtlamaz:

• Önbellek kapalıyken veya oturum açmış kullanıcılar için çok yüksek TTFB (örneğin 1–2 saniye).
• MySQL slow query log içinde sürekli tekrar eden SELECT * FROM wp_options … sorguları.
• phpMyAdmin veya benzeri araçlarda wp_options tablosunun yüz binlerce kayda ulaşması.
• Sunucu tarafında CPU kullanımının, özellikle trafik arttığında hızla tavana vurması.

Siteniz belli saatlerde yavaşlıyorsa ve özellikle MySQL tarafında takılmalar görüyorsanız, CPU, IO ve MySQL darboğazı teşhisi rehberimizde anlattığımız yöntemlerle darboğazın kaynağını araştırabilirsiniz. wp_options’ın payını sorgu süreleri ve kaynak kullanımı ölçümleriyle değerlendirin.

Önce Veritabanının Tamamını Karşılaştırın

Yalnızca wp_options boyutuna bakmayın. Aşağıdaki salt okunur sorguda your_database_name yerine hedef veritabanını yazın; sonraki örneklerde de wp_ önekini gerçek tablo adlarıyla değiştirin. Multisite kurulumunda hedef siteyi ve ağ tablolarını ayrıca belirleyin. Yetkiniz yoksa hosting yöneticisinden rapor isteyin.

SELECT 
  TABLE_NAME, 
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
ORDER BY size_mb DESC;

DATA_LENGTH + INDEX_LENGTH, InnoDB için bildirilen yaklaşık veri/indeks tahsisidir; silinebilir kayıt miktarı veya işlem için gereken boş alan değildir. 1024² böleni nedeniyle size_mb sütunundaki birim MiB’dir. Tablo büyüklüğü ve büyüme hızı, sorgu süreleriyle birlikte araştırma önceliği belirler; büyük tablo tek başına gereksiz veri veya performans sorunu kanıtı değildir.

Tablonun Boyutu ve Autoload Toplamını Ölçmek

İlk adım, wp_options tablonuzun kabaca ne durumda olduğunu görmektir. Aşağıdaki salt okunur SELECT sorgularını SSH ile MySQL kabuğundan veya phpMyAdmin SQL sekmesinden çalıştırabilirsiniz; farklı bir tablo öneki kullanıyorsanız wp_options adını uyarlayın. İkinci ve üçüncü sorgu, WordPress 6.6 ve sonrası için varsayılan etkin autoload değerlerini (yes, on, auto-on, auto) kapsar. wp_autoload_values_to_autoload filtresi bu kümeyi daraltabilir; sitenize özgü toplamı ölçmek için aynı adlı çekirdek işlevinin gerçek sonucunu kontrol edip IN listesini buna göre uyarlayın. İkinci sorgu, seçilen option_value alanlarının saklanan bayt uzunluklarını toplar ve 1024’e bölerek KiB cinsinden verir; tablo/indeks boyutunu veya PHP bellek tüketimini ölçmez. Ayrıca wp_load_alloptions önbellek ve filtrelerden etkilenir; veritabanı seçimi boşsa tüm seçeneklere başvurabilir. Bu nedenle statik SQL sonucu, çalışma anında kullanılan nihai autoload verisiyle veya her istekte fiziksel sorgu çalışmasıyla eş tutulmamalıdır:

SELECT COUNT(*) AS toplam_kayit
FROM wp_options;

SELECT SUM(LENGTH(option_value)) / 1024 AS kb_autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

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;

Autoload verilerini birkaç yüz KB düzeyinde tutmak bir optimizasyon hedefi olabilir, ancak evrensel bir sınır değildir. Megabayt düzeyindeki verileri inceleyin; temizlik veya yeniden yapılandırma kararını kayıtların kullanımına ve ölçülen performans etkisine göre verin.

Slow Query Log ve EXPLAIN Çıktılarını İncelemek

Eğer VPS veya dedicated sunucu kullanıyorsanız, MySQL slow query log erişiminiz varsa, kaydedilen wp_options sorgularını inceleyebilirsiniz. Aşağıdaki SELECT, WordPress 6.6 ve sonrasının varsayılan etkin autoload değerlerine göre satır seçimini gösterir. wp_autoload_values_to_autoload filtresi listeyi daraltabilir; sitenizde kullanılan listeyi kontrol edin. Örneği her sürümde aynen veya her istekte çalışan bir sorgu olarak kabul etmeyin: önbellek ve wp_load_alloptions filtreleri çalışma anındaki davranışı değiştirebilir. Farklı tablo öneki kullanıyorsanız wp_options adını uyarlayın:

SELECT option_name, option_value
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Bu tür sorgular sık çalışıyor ve büyük miktarda veri okuyorsa veritabanı yükünü artırabilir; tablo boyutu tek başına disk I/O veya CPU darboğazını kanıtlamaz. Ayrıca, option_name üzerinden yapılan aramaların erişim planını ve mevcut indekslerin kullanımını EXPLAIN ile inceleyebilirsiniz. Sunucu tarafı ayarları ile ilgili daha geniş bir perspektif için WordPress için sunucu tarafı optimizasyon rehberimize de göz atmanız faydalı olacaktır.

Güvenli Temizlikten Önce: Yedek ve Test Ortamı

Her Şeyden Önce Tam Yedek Alın

Veritabanı üzerinde manuel sorgular çalıştıracağımız için, ilk ve tartışmasız kuralımız: Önce tam yedek. Üretim veritabanında değişiklik yapmadan önce şu güvenlik adımlarını uygulayın:

• Tam veritabanı yedeği (mysqldump, panel yedeği veya otomatik yedek sistemi).
• Mümkünse dosya sistemi dahil tam site yedeği.
• Yedeğin geri yüklenebilir olduğunu en az bir kez test etmiş olmak.

Bu konuda adım adım fikir almak isterseniz, WordPress yedekleme stratejileri yazımızda hem paylaşımlı hosting hem de VPS tarafında otomatik yedek ve geri yükleme senaryolarını detaylıca anlattık. Daha veritabanı odaklı bir bakış için de MySQL veritabanı yedekleme stratejileri rehberimizden faydalanabilirsiniz.

Staging / Test Ortamı Üzerinde Çalışmak

Özellikle yoğun trafikli e-ticaret sitelerinde, veritabanı temizliği ve autoload ayarlarını doğrudan canlı ortamda denemek risklidir. İdeal senaryo:

• Canlı sitenizi staging alanına klonlayın; ödeme entegrasyonlarını test moduna alın ve gerçek müşterilere e-posta veya dış sistemlere üretim işlemi gönderilmesini engelleyin.
• Yalnızca seçtiğiniz ve kapsamını doğruladığınız bakım yöntemini staging’de test edin; çalıştırılmaması gereken karşı örnekleri uygulamayın.
• Kritik formlar, ödeme, giriş/çıkış ve arama akışlarını kontrol edin.
• Canlı değişiklik için güncel yedek ve ayrı yürütme planını doğrulayın; sınırsız staging örneklerini büyük canlı tablolara taşımayın.

Staging için ayrı bir alt alan adı ve veritabanı kullanmak bir seçenektir. Ancak bunlar tek başına kaynak izolasyonu sağlamaz; aynı sunucudaki yoğun testler canlı trafiği etkileyebilir. Test ortamının canlı veritabanına veya üretim entegrasyonlarına bağlanmadığını doğrulayın. Canlı değişiklikten hemen önce güncel, geri yüklenebilir bir yedek alın. Staging başarısı, büyük canlı tabloda sınırsız silme sorgusunu güvenli yapmaz; aşağıdaki partili üretim planını ayrıca doğrulayın.

wp_options Temizliği: Transient, Cache ve Yetim Kayıtlar

1. Transient Temizliğinde Süre ve Kapsam Kontrolü

WordPress ve pek çok eklenti, geçici verileri transient adı verilen mekanizma ile saklar. Temizlik değerlendirmesinde süresi geçmiş kayıtları hâlâ geçerli olanlardan ayırmak gerekir; yalnızca ad öneki bir kaydın yetim veya silinebilir olduğunu göstermez. Veritabanında saklanan transient kayıtlarında şu ad önekleriyle karşılaşabilirsiniz:

• _transient_…
• _site_transient_…
• _transient_timeout_…
• _site_transient_timeout_…

Aşağıdaki SQL, süresi geçmiş transient temizliği için güvenli bir örnek değildir; bu amaçla çalıştırmayın. Süre kontrolü yapmadığından hâlâ geçerli değerleri de silebilir ve timeout kayıtlarını bırakır. Ayrıca LIKE desenlerindeki kaçırılmamış alt çizgiler tek karakter jokeridir; eşleşme kapsamı görünen öneklerden daha geniş olabilir. Süresi geçmiş kayıtları hedefleyen, değer ve timeout eşlerini birlikte ele alan bir yöntem kullanılmalıdır:

-- ÇALIŞTIRMAYIN: Süre denetimsiz, hatalı silme karşı örneği.
-- DELETE FROM wp_options
-- WHERE option_name LIKE '_transient_%'
--   AND option_name NOT LIKE '_transient_timeout_%';

-- DELETE FROM wp_options
-- WHERE option_name LIKE '_site_transient_%'
--   AND option_name NOT LIKE '_site_transient_timeout_%';

Yorum satırlarına alınmış bu karşı örnek süresi geçmiş kayıtlarla sınırlı değildir: süreyi denetlemez, değer/timeout çiftlerini birlikte silmez ve LIKE içindeki alt çizgileri literal eşleştirmez. Silme öncesinde adayları SELECT ile incelemek bu hataları düzeltmez. Aşağıdaki WP-CLI komutu seçili kurulumun geçerli sitesindeki veritabanı kayıtlarını süreye göre temizler. Multisite’ta her site için --url=https://site.example ile hedefi seçin; ağ/site transient’leri için ayrıca wp transient delete --expired --network kullanın. Bunlar harici nesne önbelleğini temizlemez. Site transient’leri tek sitede options, multisite’ta sitemeta tablosunda tutulur.

wp transient delete --expired

Bu temizlikle kaldırılabilecek veri miktarı, kullanılan eklentilere ve biriken transient kayıtlarının boyutuna bağlıdır.

2. Kullanılmayan Eklenti ve Tema Ayarlarını Tespit Etmek

Bir diğer klasik şişme sebebi, kaldırılmış eklentilerin geride bıraktığı ayarlardır. Bazı eklentiler kaldırılırken ayarlarını geride bırakabilir. Devre dışı bırakılan ancak yeniden kullanılacak eklentilerin ayarları ise silme adayı sayılmamalıdır. Stratejik yaklaşım:

1. WordPress yönetim panelinizde kurulu eklentilerin ve temaların listesini çıkarın; devre dışı olan ancak yeniden kullanılacakları da işaretleyin.
2. wp_options içinde option_name alanında ilgili eklentinin adına, prefixine veya vendor ismine göre arama yapın. Örnek: %woocommerce%, %yoast%, %wpml%, %elementor% vb.
3. İsim eşleşmesini tek başına silme gerekçesi saymayın. Kaydı hangi bileşenin kullandığını ve veriye artık ihtiyaç olmadığını doğruladıktan sonra, önce staging ortamında silmeyi deneyin.

Örneğin, artık hiç kullanmadığınız bir form eklentisinin ayarları şu isimlerde olabilir:

• xyz_form_settings
• xyz_form_version
• xyz_form_logs

Bu eklentiyi tamamen hayatınızdan çıkardıysanız, bunlar güvenle silinebilecek kayıtlar olabilir. Ancak burada tek bir altın kural var: Emin olmadığınız kaydı silmeyin; önce yedeğe, sonra staging ortamına güvenin.

3. Log, İstatistik ve Büyük Boyutlu Kayıtları İncelemek

Bazı eklentiler (ve özel yazılmış fonksiyonlar), log verilerini veya istatistikleri wp_options içinde tutarlar. Örneğin:

• debug_log, api_error_log vb isimler.
• binlerce satır URL, IP, user-agent içeren büyük diziler.

Bu kayıtlar autoload = no olarak işaretlenmiş olsalar bile, büyük hacimde biriktiklerinde tablonun boyutunu ve yedekleme/taşıma sürelerini artırabilir. Bu tür kayıtları tespit etmek için büyük boyutlu option_value alanlarını listeleyebilirsiniz:

SELECT option_id, option_name, LENGTH(option_value) AS boyut, autoload
FROM wp_options
ORDER BY boyut DESC
LIMIT 50;

Büyük log verisi bulursanız, hangi kayıtların operasyonel olarak gerekli olduğunu belirleyin. Eklentinin desteklediği saklama süresini veya uygun dosya/özel tablo hedefini değerlendirin; yalnızca boyutu küçültmek için gerekli logları kapatmayın. Veri sahibinin ihtiyaçlarını ve uygulama davranışını staging üzerinde doğrulayın.

Autoload Şişmesini Kontrol Altına Almak

Toplam Autoload Boyutunu Ölçmek ve Hedef Belirlemek

Aşağıdaki sorgu WordPress 6.6+ varsayılan autoload değerlerine sahip kayıtların saklanan option_value baytlarını toplar; 1024’e bölünen sonuç KiB’dir. Filtreler etkin değer kümesini daraltabilir: siteye özgü ölçüm için wp_autoload_values_to_autoload() sonucuyla SQL filtresini eşleştirin. Bu ölçüm PHP bellek tüketimi, sorgu sıklığı veya önbellek/filtreler sonrası çalışma zamanı yükü değildir. wp_options adını hedef sitenin gerçek tablo adıyla değiştirin.

SELECT SUM(LENGTH(option_value)) / 1024 AS kb_autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

Ölçümlere göre uyarlanabilecek örnek boyut hedefleri:

• Küçük sitelerde (blog, kurumsal site): 200–400 KB aralığı.
• Orta ölçekli sitelerde (içerik/kurumsal + birkaç entegrasyon): 400–800 KB aralığı.
• Çok büyük sitelerde bile mümkünse birkaç MB sınırını zorlamamak.

Bu aralıklar doğrulanmış performans eşikleri değildir. Hedefi sitenin ihtiyaçlarına göre belirleyin; boyutun yanında yanıt süresi ve bellek kullanımını da ölçerek değişikliğin yararını değerlendirin.

Hangi Veriler Autoload Olmamalı?

Öncelikle nadiren okunan ve büyük yer kaplayan verilerin autoload dışında tutulmasını değerlendirin. Kararı yalnızca veri adına değil, kullanım sıklığına ve ölçülen etkisine göre verin. İncelenebilecek adaylar:

• Belli sayfalarda kullanılan, site genelini ilgilendirmeyen ayarlar.
• Geçici cache sonuçları (transient verileri).
• Büyük dizi/nesne yapıları; özellikle rapor veya toplu veri içerenler.
• Nadiren kullanılan panel içi rapor ayarları, iç istatistikler vb.

Diğer yandan, siteurl, home, aktif tema ve çekirdek ayarlar gibi kritik verileri sırf autoload toplamını küçültmek için değiştirmeyin. Bunların yükleme davranışını değiştirmek, kullanım biçimlerinin ve etkilerinin ayrıca incelenmesini gerektirir.

Autoload Bayraklarını Düzenlerken Dikkat Edilmesi Gerekenler

WordPress 6.6+ varsayılan autoload kümesindeki en büyük kayıtları saklanan bayt sayısına göre listelemek için aşağıdaki sorguyu kullanın. Özel filtre varsa SQL kümesini wp_autoload_values_to_autoload() sonucuna uyarlayın; tablo adını hedef siteye göre değiştirin. Bu liste PHP belleğini veya önbellek/filtreler sonrası gerçek yükü ölçmez.

SELECT option_id, option_name, LENGTH(option_value) AS boyut
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY boyut DESC
LIMIT 50;

Bir kaydın cache veya raporla ilgili görünmesi yeterli değildir. İlgili eklentinin belgelerinden veya kodundan kullanımını inceleyip autoload dışında tutulmasının uygun olduğuna karar verirseniz, önce staging ortamında şu değişikliği değerlendirin:

Bu işlem WordPress 6.4+ ve WP-CLI erişimi gerektirir. Doğru kurulum dizininde çalışın; multisite’ta hedef siteyi --url ile seçin. Önce seçtiğiniz kaydın mevcut autoload değerini kaydedin ve veritabanı yedeğini alın. Yer tutucu adı, kullanımını doğruladığınız gerçek seçenek adıyla değiştirerek staging ortamında uygulayın:

wp eval 'wp_set_option_autoload_values( array( "ornek_option_adi" => false ) );'

Bu API değişiklikte WordPress seçenek önbelleğini de tutarlı tutar; autoload dışına alınan kaydı alloptions koleksiyonundan çıkarır. Böylece kalıcı nesne önbelleği kullanırken de doğrudan SQL’in atladığı güncelleme yolu kullanılır; paylaşılan önbelleğin tamamını boşaltmanız gerekmez. Ardından bayrağı yeniden kontrol edin ve seçeneği kullanan işlevleri staging’de test edin. Sonuç uygunsa canlıda hedef kurulum/siteyi ve yedeği doğrulayıp aynı API yolunu uygulayın, ilgili işlevleri tekrar kontrol edin. Ne yaptığınızdan emin değilseniz çekirdek ve kritik ayarların autoload bayrağıyla oynamayın.

Büyük WordPress Tablolarını İncelemek ve Bakımını Planlamak

wp_postmeta yazı, sayfa ve özel içerik türlerinin meta verilerini; wp_posts ise içerikleri ve revizyonları barındırır. Yorumlar ve yorum meta verileri ayrı tablolardadır. Eklentiler kendi log, istatistik veya oturum tablolarını da oluşturabilir. Bir tablonun büyük olması, bütün kayıtlarının gereksiz olduğu anlamına gelmez.

Canlı Veride Partili İşlem İçin Ayrı Bir Plan Hazırlayın

Bu bölümdeki sınırsız DELETE örnekleri yalnızca küçük, doğrulanmış staging veri kümeleri içindir. Gerçek verinin korunması, geri yükleme denemesi ve kritik uygulama akışlarının testi gerekir. Büyük canlı tabloda aynı ifadeleri olduğu gibi çalıştırmayın; salt okunur sayımların bile büyük tablolarda maliyetli olabileceğini hesaba katın.

1. Veri sahibiyle saklama süresini, ilişkileri ve gerçekten silinebilecek kayıtları belirleyin; güncel yedeğin geri yüklenebildiğini doğrulayın.
2. İndeksli anahtarlar veya gözden geçirilmiş anahtar aralıklarıyla küçük partileri seçen, eşzamanlı yazıları ve ilgili önbelleği ele alan bir yürütme planı tasarlayın. Silme kapsamını önce SELECT ile inceleyin; uygulamaya özgü ilişkileri yalnızca ad önekinden çıkarmayın.
3. Etkilenen satır sayısını, sorgu/transaction süresini ve kilit beklemelerini ölçün. Her doğrulanmış partiyi bağımsız tamamlayıp partiler arasında commit edin; bütün silmeyi tek büyük transaction içinde biriktirmeyin. Commit edilmiş partilerin geri alınması yedek veya ayrı telafi planı gerektirir.
4. Canlı istek gecikmesini, veritabanı yükünü, undo/redo hacmini, boş alanı ve varsa replikasyon gecikmesini izleyin. Kabul sınırları aşılırsa yeni partileri durdurun; devam eden işi iptal etme ve henüz commit edilmemiş işlemi rollback etme yöntemini önceden belirleyin.
5. Sonuç ve uygulama davranışı doğrulanmadan sonraki partiye geçmeyin. Evrensel bir güvenli satır sayısı veya süre yoktur; partiyi gerçek sorgu planına ve yüke göre ayarlayın.

MySQL’de tek tabloyu hedefleyen DELETE ... LIMIT silinen satır sayısını sınırlar; sorgunun süresini veya kilit beklemesini garanti etmez. Aşağıdaki çok tablolu join silmesine sonradan LIMIT eklemek geçerli bir çözüm değildir: çok tablolu DELETE bu söz dizimini desteklemez. Anahtar seçimi ve silme akışı ayrıca tasarlanmalıdır. WordPress API’lerini kullanan bir bakım aracı da büyük veride otomatik olarak partili veya düşük maliyetli çalışmaz; davranışını doğrulayın.

wp_postmeta Boyutu ve Yetim Kayıtlar

Önce hedef veritabanını seçin; örnekteki veritabanı ve tablo adlarını uyarlayın. İlk sorgu gerçek meta kayıtlarını sayar; ikinci sorgu ayrı olarak bildirilen veri/indeks tahsisini MiB cinsinden verir. information_schema.TABLES satırlarını saymak, wp_postmeta kayıt sayısını vermez. Büyük InnoDB tablolarında tam sayım pahalı olabilir.

SELECT COUNT(*) AS row_count
FROM wp_postmeta;

SELECT
  ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
  AND TABLE_NAME = 'wp_postmeta';

Ürün özellikleri, sayfa oluşturucu verileri veya artık kullanılmayan bileşen kayıtları inceleme adayı olabilir. Kaydın hangi kod tarafından kullanıldığını ve saklama gereksinimini doğrulayın. Aşağıdaki salt okunur sorgu yalnızca karşılık gelen yazı kaydı bulunmayan meta satırlarını sayar; eşleşmeme durumu tek başına silme onayı değildir.

SELECT COUNT(*) AS orphan_count
FROM wp_postmeta m
LEFT JOIN wp_posts p ON m.post_id = p.ID
WHERE p.ID IS NULL;

Aşağıdaki sınırsız silme yalnızca küçük, doğrulanmış staging veri kümesi ve geri yüklenebilir yedek içindir. Koşula uyan bütün yetim meta satırlarını siler; örneklemle sınırlı değildir. WordPress hook ve önbellek yollarını atlar. Büyük canlı veri için yukarıdaki anahtarlı parti planı, eşzamanlı yazı ve önbellek yönetimi ayrıca tasarlanmalıdır.

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

Revizyonlar, Çöp Kutusu ve Spam Yorumlar

Revizyonlar geri dönüş geçmişidir; silmeden önce editörlerin kaç sürüme ihtiyaç duyduğunu belirleyin. Rutin bakımda WordPress’in revizyon/yorum araçlarını tercih edin; kapsam ve büyük veri davranışlarını yine doğrulayın.

Sonraki sınırsız DELETE yalnızca küçük, doğrulanmış staging verisi ve geri yüklenebilir yedek içindir. Yaş filtresi olmadan tüm revizyonları siler. Yalnızca wp_posts kayıtlarını etkilediği için ilişkili postmeta yetim kalabilir. Ardından yetim kaydı yeniden kontrol edin; yukarıdaki sınırsız silmeyi otomatik olarak zincirlemeyin. Canlı büyük veri için ayrı parti planı gerekir; doğrudan SQL, WordPress’in uygulama düzeyindeki temizliğini atlar.

DELETE FROM wp_posts
WHERE post_type = 'revision';

Gelecekteki revizyon saklama sayısını düzenlemek için wp-config.php içinde WordPress yüklenmeden önce mevcut tanımı değiştirin veya yoksa ekleyin; aynı sabiti iki kez tanımlamayın. 10 yalnızca örnektir. Dosyayı değiştirmek mevcut revizyonları o anda topluca silmez; sonraki revizyon kaydetme işlemleri, geçerli sınır ve filtrelere göre en eski sürümleri temizleyebilir. Bu ayarı geçmiş verinin anlık temizliğiyle karıştırmayın.

define( 'WP_POST_REVISIONS', 10 ); // or a lower number

Aşağıdaki iki sınırsız ifade yalnızca küçük, doğrulanmış staging verisi ve geri yüklenebilir yedek içindir. İlk ifade spam ve çöp durumundaki yorumları, ikinci ifade ise eski yetimler dâhil hiçbir yoruma bağlı olmayan tüm yorum meta verilerini siler. İki kapsamı ayrı doğrulayın. Doğrudan SQL, WordPress yorum temizliği ve önbellek güncellemelerini atlar; rutin işte WordPress’in yorum araçlarını tercih edin. Büyük canlı veride sorguları aynen çalıştırmayın veya tek büyük transaction içine almayın; anahtarlı parti planı gerekir.

DELETE FROM wp_comments
WHERE comment_approved = 'spam' 
   OR comment_approved = 'trash';

DELETE FROM wp_commentmeta
WHERE comment_id NOT IN (SELECT comment_ID FROM wp_comments);

Çöp kutusunun saklama süresini ve zamanlanmış temizliğin çalışmasını kontrol edin. Spam saklama kuralını ayrıca inceleyin; çöp temizliğinin spamı da aynı kuralla sildiğini varsaymayın.

Eklenti Logları ve Saklama Politikası

Log, istatistik, güvenlik veya oturum tabloları büyüyebilir. Önce eklentinin yerleşik saklama/purge özelliğini araştırın; operasyonel ve kayıt tutma ihtiyaçlarına uygun süreyi veri sahibiyle belirleyin. Desteklenen yöntem yoksa geliştiriciden tablo ilişkilerini ve silme yolunu öğrenin. Oturum veya log adı, verinin gereksiz olduğunu kanıtlamaz.

Varsayımsal wp_plugin_logs için aşağıdaki sınırsız sorgu, yalnızca küçük, doğrulanmış staging verisinde ve geri yüklenebilir yedekle 90 günlük kesimi gösterir. created_at alanının tarih/saat türünde ve NOW() ile aynı zaman temelinde olduğunu; veri sahibinin 90 günü ve eklentinin bu silme yolunu kabul ettiğini doğrulayın. Bu bir canlı cron tarifi değildir. Büyük tablolar için ayrı anahtarlı parti planı, izleme ve durdurma koşulları gerekir.

DELETE FROM wp_plugin_logs
WHERE created_at < NOW() - INTERVAL 90 DAY;

Log tablolarını gelişigüzel boşaltmayın veya kaldırmayın; eklenti mevcut şemayı ve ilişkileri bekleyebilir. Yalnızca doğrulanmış kapsamı otomatikleştirin; rehberdeki tüm SQL örneklerini bir zamanlanmış göreve koymayın.

OPTIMIZE ve ANALYZE: Amaç ve Kapasite Kontrolü

Büyük silmelerden sonra depolamada yeniden kullanılabilir alan oluşabilir. OPTIMIZE TABLE depolamayı yeniden düzenleyebilir; işletim sistemine alanın geri dönmesi motor ve tablespace düzenine bağlıdır. ANALYZE TABLE optimizer istatistiklerini günceller, alan açmaz. İkisi de sorguların hızlanmasını garanti etmez; aşağıdaki ifadeler zorunlu bir işlem sırası değildir.

Yeniden oluşturmadan önce kapasiteyi doğrulayın. Veri/indeks boyutlarıyla birlikte hem MySQL geçici depolama konumunda hem tablonun dosya sisteminde gerçekten kullanılabilir alanı inceleyin. MySQL 8.0 InnoDB işlemleri mevcut tabloya ek olarak geçici sıralama dosyaları ve ara yeniden oluşturulmuş tablo için ciddi alan gerektirebilir. Evrensel bir boş alan çarpanına güvenmeyin; tam MySQL/MariaDB sürümü, motor ve işlem için gereksinimleri doğrulayın. Alan veya yetki doğrulanamıyorsa işlemi erteleyip veritabanı yöneticisiyle görüşün.

OPTIMIZE TABLE wp_options, wp_postmeta, wp_posts, wp_comments;
ANALYZE TABLE wp_options, wp_postmeta, wp_posts, wp_comments;

Seçilen işlemi staging’de doğrulayın; güncel yedek, düşük trafik penceresi ve izleme planlayın. MySQL 8.0 InnoDB OPTIMIZE TABLE tabloyu yeniden oluşturur. Online DDL kesintiyi azaltabilse de hazırlık/commit aşamalarında özel kilitler vardır; bazı ayarlar veya FULLTEXT indeksleri tablo kopyalama yöntemini gerektirir. Uzun transaction ve kilit beklemelerini kontrol edin. ANALYZE de motor ve sürüme bağlı kilitleme davranışı gösterir. Kabul edilemez yük veya bloklama durumunda erteleme koşulunu önceden belirleyin.

Depolama Motoru ve İndeksleri Kontrol Edin

InnoDB satır düzeyinde kilitleme ve çökme sonrası kurtarma özellikleri sunar. Aşağıdaki salt okunur sorguda gerçek veritabanı ve tablo adlarını kullanarak motorları inceleyin; yalnızca tablo adına bakıp dönüşüm yapmayın.

SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
  AND TABLE_NAME IN ('wp_posts','wp_postmeta','wp_options','wp_comments');

MyISAM bir tabloyu InnoDB’ye dönüştürme kararı, tam sürüm/motor uyumluluğu, mevcut indeks ve uygulama davranışı incelendikten sonra verilir. Aşağıdaki örneği önce staging’de; güncel geri yüklenebilir yedek, gerekli geçici/ara tablo alanı ve kilitleme etkisini doğrulayarak deneyin. Canlı dönüşüm için ayrıca bakım penceresi ve izleme gerekir.

ALTER TABLE wp_posts ENGINE=InnoDB;

Diğer her tablo için kararı ayrı verin; bütün tabloları otomatik olarak dönüştürmeyin. Tablo başına veri/indeks boyutunu, disk kapasitesini, uyumluluğu ve yedekten dönüş yolunu tekrar doğrulayın.

Kurulu WordPress sürümünün standart indekslerini inceleyin. wp_postmeta(post_id, meta_key) bileşik indeksini zorunlu çekirdek indeksi saymayın; mevcut indeksler, gerçek sorgular ve EXPLAIN planlarına göre değerlendirilecek bir adaydır. Gereksiz indeksler yazma ve depolama maliyetini artırabilir. Ölçüm olmadan indeks eklemeyin.

Geliştiriciler İçin En İyi Uygulamalar: Şişmeyi Baştan Önlemek

add_option Kullanırken Autoload Parametresi

Kendi geliştirdiğiniz tema veya eklentilerde, WordPress API fonksiyonlarını kullanırken autoload parametresini mutlaka bilinçli kullanın. Örneğin:

add_option( 'ornek_ayar', $deger, '', 'no' );

Bu şekilde oluşturduğunuz ayar, varsayılan olarak autoload edilmez. Özellikle:

• Büyük dizi/nesne saklıyorsanız,
• Nadiren kullanılan yönetim paneli ayarlarıysa,
• Cache/rapor gibi isteğe bağlı okunan verilerse

autoload parametresini no kullanmak, gereksiz yüklemeyi azaltmaya yardımcı olabilir; performans etkisini ölçerek değerlendirin.

wp-cron, Zamanlanmış Görevler ve Temizlik

wp_options tablosundaki bazı şişmeler, düzenli olarak çalışması gereken ama takılan veya çok sık tetiklenen cron görevlerinden de kaynaklanabilir. Örneğin başarısız entegrasyon denemeleri her seferinde yeni bir kayıt açıyorsa, kısa sürede on binlerce satır birikebilir. Bu yüzden:

• wp-cron görevlerini, başarısızlıklarını ve tekrar çalışma sıklığını izleyin.
• Görevin gerçekten daha seyrek çalışabileceğini doğrulamadan sıklığını azaltmayın. Gerçek cron kullanımı zamanlamayı düzenleyebilir; hatalı silme kapsamını veya büyük işlem yükünü düzeltmez.
• Yalnızca staging ve üretim parti planı doğrulanmış temizlik/saklama görevlerini otomatikleştirin.

Bu konuda daha derin bir bakış için wp-cron devre dışı bırakma ve gerçek cron job kurulumu rehberimizi incelemenizi öneririz.

Persistent Object Cache Kullanımı (Redis vb.)

WordPress nesne önbelleği varsayılan olarak istek ömrüyle sınırlıdır. Redis veya Memcached gibi bir arka uçla uygun entegrasyon kurularak kalıcı hale getirildiğinde, wp_options verileri için tekrarlanan veritabanı erişimlerini azaltabilir. Özellikle:

• Kalıcı nesne önbelleği, tekrar eden seçenek erişimlerinin veritabanı maliyetini azaltabilir.
• Büyük seçenek koleksiyonunun aktarım ve PHP işleme maliyeti devam edebilir. Redis kullanımı verinin gerekli olup olmadığını kanıtlamaz; temizlik kararını sahiplik, kullanım ve ölçülen etkiye göre verin.

Kalıcı cache dünyasına giriş yapmak için Redis cache performans rehberimize göz atabilirsiniz. Kalıcı nesne önbelleği planlarken seçilen altyapının Redis çalıştırma veya bir Redis hizmetine bağlanma olanaklarını ve WordPress entegrasyonunu değerlendirin.

Veritabanı ve Hosting Katmanında Ek Optimizasyonlar

İndeksler ve MySQL Tarafı Ayarlar

Modern WordPress kurulumlarında wp_options için option_id ve option_name üzerinde gerekli indeksler zaten mevcuttur. Yine de çok büyük tablolarda, sorgu planlarını incelemek önemlidir. EXPLAIN çıktısını yalnızca Using where; Using index gibi notlara bakarak iyi veya kötü diye sınıflandırmayın. Sorgu planını ve ölçülen maliyeti birlikte inceleyerek ek indeks ihtiyacını değerlendirin.

MySQL ayarlarını kullanılan sürüm ve ölçülen iş yüküne göre değerlendirin; aşağıdaki adları her kurulumda geçerli bir ayar listesi olarak kullanmayın:

• innodb_buffer_pool_size
• Redo log kapasitesi: MySQL 8.0.30+ için innodb_redo_log_capacity; önceki sürümlerde tarihsel ayarlar innodb_log_file_size ve innodb_log_files_in_group’dur. Sürümünüzün yöntemini kullanın.
• MySQL query cache: 5.7.20’de kullanımdan kaldırılmak üzere işaretlendi, 8.0.3’te kaldırıldı; güncel MySQL için yapılandırmayın. Bu sürüm bilgisi MariaDB’ye genellenmez. WordPress nesne önbelleği ve sayfa önbelleği ayrı uygulama katmanlarıdır; query cache ayarının birebir yerine geçmezler.

Daha geniş bir MySQL tuning ve yedekleme perspektifi için, yukarıda bahsettiğimiz MySQL veritabanı yedekleme ve yönetimi rehberini mutlaka okumanızı öneririz.

TTFB ve Genel Sayfa Hızına Etkisi

wp_options içindeki gereksiz verilerin ve autoload yükünün azaltılması, veritabanı erişimi veya PHP işlemesi darboğaz oluşturuyorsa TTFB’yi iyileştirebilir. Etkiyi belirlemek için temizlik öncesi ve sonrasında aynı koşullarda ölçüm yapın. PHP-FPM, OPcache, Redis ve MySQL ayarlarıyla birlikte değerlendirilebilecek olası kazanımlar:

• Daha az autoload verisi işlenmesiyle PHP bellek kullanımının azalması,
• Veritabanından okunan gereksiz veri miktarının azalması.

HTTP/2, HTTP/3 ve CDN ise farklı katmanlardaki iyileştirmelerdir; wp_options temizliğinin sonucu olarak değerlendirilmemelidir.

Bu noktada, sunucu tarafı optimizasyonu ile veritabanı temizliğini birlikte düşünmek için WordPress sunucu optimizasyon rehberimize geri dönüp, tüm resmi bir arada değerlendirmeniz iyi olacaktır.

Doğru Hosting ve Kaynak Planlaması

Autoload ve büyük tabloları inceleyip sorgu, kilit ve bağlantı yönetimi sorunlarını değerlendirdikten sonra ölçümler sürekli CPU, bellek veya depolama yetersizliği gösteriyorsa kapasite artışını düşünün. Yavaş sorgu veya yüksek bağlantı sayısı tek başına donanım eksikliğini kanıtlamaz. Şu seçenekleri değerlendirebilirsiniz:

• İş yükü ve erişim ihtiyacını karşılayan paylaşımlı hosting planı,
• Ölçülen gereksinime göre VPS, fiziksel sunucu veya ayrı veritabanı/önbellek hizmeti

CPU/RAM limitlerini, depolama performansını, kaynak tahsis koşullarını ve MySQL yönetim yetkisini sözleşmeden doğrulayın. Redis gibi kalıcı nesne önbelleği için WordPress entegrasyonu da gerekir. Daha büyük paket veya farklı sunucu türü tek başına hızlanma garantisi değildir.

Uzun Vadeli Bakım: Büyümeyi ve Sorgu Maliyetini İzlemek

Düzenli Kontrol ve Otomasyon

Kontrol sıklığını tablonun büyüme hızına, iş yüküne ve saklama ihtiyaçlarına göre seçin. Örneğin üç aylık autoload incelemesi veya yıllık ayrıntılı bakım bir başlangıç planı olabilir; yoğun büyüyen sistemlerde daha sık kontrol gerekir. Bunlar otomatik silme aralıkları değildir.

• Autoload toplamını, büyük tabloların veri/indeks boyutunu ve sorgu sürelerini aynı yöntemle izleyin.
• Yeni eklenti, güncelleme ve trafik değişimlerini büyümeyle karşılaştırın; zaman ilişkisini tek başına neden kanıtı saymayın.
• Süresi geçmiş transient, doğrulanmış log saklama ve çöp kutusu görevlerini kapsam ve çalışma sonuçlarıyla kontrol edin. OPTIMIZE işlemini takvime bağlı bir zorunluluk saymayın.

Küçük işletmeler için yıllık bakım takvimi oluştururken, veritabanı kontrollerini de eklemek mantıklı olacaktır. DCHost blogunda paylaştığımız genel bakım ve güvenlik rehberleri ile bu rutini zenginleştirebilirsiniz.

Geliştirici ve Sistem Tarafının Birlikte Çalışması

Performans sorunları her zaman yalnızca veritabanı veya sunucu ayarıyla çözülmez. Sağlıklı bir WordPress altyapısında:

• Geliştirici, wp_options ve autoload kullanımını bilinçli tasarlar.
• Sistem yöneticisi, MySQL, PHP-FPM, OPcache, Redis gibi katmanları doğru boyutlandırır.
• Hosting sağlayıcısının altyapı izleme, darboğaz raporlama ve iyileştirme önerileri konusundaki sorumlulukları, hizmet kapsamına göre netleştirilir.

Bu koordinasyon, uygulama, veritabanı ve sunucu katmanlarını birlikte ele almayı ve tespit edilen sorunlar için sorumluları belirlemeyi sağlar.

Sonuç: Gereksiz Veriyi Ayırın, Etkiyi Ölçün

WordPress veritabanı optimizasyonu, yalnızca wp_options ve autoload toplamını küçültmekten ibaret değildir. Büyük postmeta, revizyon, yorum ve log tablolarının kullanımını; saklama ihtiyacını, sorgu planını ve bakım maliyetini birlikte inceleyin. Gereksiz verinin azaltılması ancak gerçek darboğazı etkilediği ölçüde yanıt süresini veya kaynak kullanımını iyileştirir.

Önce ölçüm ve geri yüklenebilir yedek; ardından staging doğrulaması ve büyük canlı veri için ayrı anahtarlı parti planı hazırlayın. Sınırsız silme örneklerini canlıya aynen taşımayın. Partiler arasında commit, izleme ve durdurma koşullarını uygulayın; yeniden oluşturma öncesinde geçici/ara tablo kapasitesini ve kilitleme etkisini kontrol edin. Aynı yükte önce/sonra TTFB, yönetim paneli yanıtı ve kaynak kullanımını karşılaştırarak sonucun yararını değerlendirin.

Dış destek alırken autoload incelemesi, büyük tablo bakımı, yedekten dönüş, sunucu yönetimi ve uygulama değişikliklerinin hangilerinin hizmete dâhil olduğunu önceden netleştirin.

Resmî Kaynaklar

• WordPress: autoload values
• WordPress: autoload API
• WP-CLI: transient deletion
• WordPress: revision retention
• WordPress: comment deletion
• MySQL 8.0: DELETE
• MySQL 8.0: OPTIMIZE TABLE
• MySQL 8.0: ANALYZE TABLE
• MySQL 8.0: online DDL space
• MySQL 8.0: InnoDB conversion