WordPress Veritabanı Optimizasyonu: wp_options ve Autoload Şişmesini Temizleme Rehberi

WordPress Veritabanında Asıl Sorun Neden Çoğu Zaman wp_options?

WordPress sitelerde veritabanı performansı konuşulunca çoğu kişi doğrudan sorgulardan, indekslerden veya MySQL ayarlarından bahseder. Ancak pratikte sahada en çok gördüğümüz problem, sessizce büyüyen ve fark edilene kadar tüm siteyi yavaşlatan tek bir tablo: wp_options. Özellikle WooCommerce, çok sayıda eklenti ve sık tema değişikliği yapılan sitelerde bu tablo, binlerce gereksiz kayıt ve kontrolsüz autoload değerleri ile şişer. Sonuç: artan TTFB, yüksek CPU kullanımı, geciken ilk byte ve zaman zaman beyaz ekranlar.

DCHost ekibi olarak yüzlerce WordPress sitesinde benzer manzaralar gördük; sorunu kökünden çözen yaklaşımın, doğrudan wp_options, autoload mantığı ve gereksiz kayıtlar üzerinde çalışmak olduğunu tekrar tekrar deneyimledik. Bu rehberde; wp_options tablosunun yapısını, autoload şişmesini nasıl tespit edeceğinizi, hangi kayıtların güvenle silinebileceğini, hangilerinin yalnızca optimize edilmesi gerektiğini ve uzun vadede bu şişmenin nasıl önleneceğini adım adım anlatıyoruz. Anlatım boyunca hem geliştirici hem de site sahibi bakış açısını koruyarak, gerçekçi ve uygulanabilir bir yol haritası sunacağız.

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: yes / no. Bu alan, WordPress performansı açısından kritik rol oynar.

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, her sayfa isteğinde belli ayarları tek tek sorgu çekmek yerine, bir kerede bellek içine almak için autoload alanını kullanır. Basitleştirilmiş haliyle:

• autoload = yes olan tüm kayıtlar, WordPress çekirdeği yüklenirken tek bir SELECT sorgusu ile okunur.
• autoload = no olan kayıtlar, sadece ihtiyaç duyulduğunda, ilgili option_name çağrıldığında sorgulanır.

Bu şu anlama gelir: Autoload = yes kayıtlarının toplam boyutu büyüdükçe, her istek başında bellek kullanımınız ve ilk sorgunuzun çalışma süresi artar. Özellikle yüzlerce kilobayt hatta megabayta ulaşan serialize edilmiş dizileri autoload ile yüklemek, TTFB üzerinde doğrudan olumsuz etki yaratır.

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.

Doğru tasarlandığında büyük veri setleri için ayrı özel tablolar veya harici cache sistemleri (Redis gibi) kullanılması gerekirken, pek çok eklenti geliştiricisi kolay olduğu için her şeyi wp_options içine yazar. İşte biz de bu rehberde, bu alışkanlığın yarattığı hasarı ortaya çıkarıp telafi edeceğiz.

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

Şişmiş wp_options Tablosunun Tipik Belirtileri

DCHost tarafında inceleme yaptığımız WordPress sitelerinde, wp_options kaynaklı performans sorunlarını genelde şu belirtilerle fark ediyoruz:

• Ö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, bunu CPU, IO ve MySQL darboğazı teşhisi rehberimizde anlattığımız yöntemlerle de doğrulayabilirsiniz. Çoğu zaman en büyük payı wp_options alır.

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

İlk adım, wp_options tablonuzun kabaca ne durumda olduğunu görmektir. Aşağıdaki sorguları SSH ile MySQL kabuğundan veya phpMyAdmin SQL sekmesinden çalıştırabilirsiniz:

SELECT COUNT(*) AS toplam_kayit
FROM wp_options;

SELECT SUM(LENGTH(option_value)) / 1024 AS kb_autoload
FROM wp_options
WHERE autoload = 'yes';

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

İyi yazılmış ve çok şişmemiş sitelerde autoload toplam boyutunun genelde birkaç yüz KB seviyesinde kalmasını tercih ederiz. Megabayt seviyelerine çıkmışsanız, ciddi bir temizlik ve yeniden yapılandırma zamanınız gelmiş demektir.

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

Eğer VPS veya dedicated sunucu kullanıyorsanız, MySQL slow query log aktifse şu tip sorguları loglarda sık sık görebilirsiniz:

SELECT option_name, option_value
FROM wp_options
WHERE autoload = 'yes';

Bu sorgu her istekte çalıştığı için, tablo şiştikçe hem disk I/O hem de CPU baskısı artar. Ayrıca, option_name üzerinden yapılan aramalarda ek indeks ihtiyacı olup olmadığını görmek için EXPLAIN çıktısını 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. DCHost olarak müşterilerimizin üretim veritabanlarında çalışmadan önce şu güvenlik adımlarını öneriyoruz:

• 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.
• Tüm wp_options sorgularını ve temizlik adımlarını staging üzerinde uygulayın.
• Siteyi gezerek, kritik formlar, ödeme adımları, giriş/çıkış, arama vb akışların sorunsuz çalıştığını teyit edin.
• Memnun kaldığınızda, aynı adımları canlı veritabanına dikkatle uygulayın.

DCHost altyapısında staging ortamlarını, ek bir alt alan adı ve ayrı bir veritabanı ile izole şekilde kurmayı öneriyoruz. Böylece yapacağınız denemeler canlı trafiği etkilemez.

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

1. Süresi Geçmiş Transient Verilerini Temizlemek

WordPress ve pek çok eklenti, geçici verileri transient adı verilen mekanizma ile saklar. Bu veriler teknik olarak otomatik temizlenmelidir, ancak pratikte sık sık yetim transient kayıtları birikir. Bunlar genelde şu isimlerle başlar:

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

Eski ve süresi geçmiş transient kayıtlarını temizlemek için kullanılabilecek tipik bir SQL ö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_%';

Daha kontrollü olmak isterseniz, önce SELECT ile hangi kayıtların silineceğini görmek mantıklı olacaktır. Alternatif olarak WP-CLI kullanıyorsanız, şu komut da işinizi görebilir:

wp transient delete --all

Bu temizlik özellikle cache eklentileri, WooCommerce, SEO eklentileri kullanan sitelerde ciddi boyutta alan açar.

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. Eklentilerin büyük kısmı kaldırılırken kendi verilerini silmez; hatta bazıları devre dışı bırakıldığında bile veriyi olduğu gibi bırakır. Stratejik yaklaşım:

1. WordPress yönetim panelinizde aktif eklentilerin ve temanın listesini çıkarın.
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. Artık kullanmadığınız eklentilere ait olduğu çok net olan kayıtları listelerken, ö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 Dev Amaçlı Kayıtları Ayıklamak

Bazı eklentiler (ve özel yazılmış fonksiyonlar), log verilerini veya istatistikleri kolaylarına geldiği için 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.

Bunlar genelde autoload = no olarak işaretlenmiş olsalar da, tabloya gereksiz yük bindirir ve yedekleme/taşıma sürelerini uzatır. 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;

Burada karşınıza gerçekten büyük veriler çıkarsa, ilgili eklentinin ayarlarından log tutma özelliğini kapatmayı veya logları dosya/tablo gibi daha uygun yerlere yönlendirmeyi düşünmelisiniz.

Autoload Şişmesini Kontrol Altına Almak

Toplam Autoload Boyutunu Ölçmek ve Hedef Belirlemek

Autoload = yes verilerinin toplam boyutunu ölçmek için yukarıda paylaştığımız sorguyu tekrar hatırlayalım:

SELECT SUM(LENGTH(option_value)) / 1024 AS kb_autoload
FROM wp_options
WHERE autoload = 'yes';

Genel pratik hedeflerimiz:

• 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 elbette katı bir kural değil; ancak DCHost tarafında gördüğümüz stabil ve hızlı WordPress kurulumlarında autoload boyutlarının genellikle bu aralıklara yakın olduğunu söyleyebiliriz.

Hangi Veriler Autoload Olmamalı?

Basit bir mantık kurabiliriz: Her istekte ihtiyaç duymadığınız hiçbir şey autoload olmamalı. Örneğin:

• 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 değişen, panel içi rapor ayarları, iç istatistikler vb.

Diğer yandan, siteurl, home, aktif tema, çekirdek ayarlar gibi veriler doğal olarak autoload olmak zorundadır. Bunlarla oynamak kesinlikle önerilmez.

Autoload Bayraklarını Düzenlerken Dikkat Edilmesi Gerekenler

En büyük autoload kayıtlarını görmek için şu sorguyu çalıştırabilirsiniz:

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

Bu listede, bariz şekilde cache/rapor/rapor ayarı gibi görünen kayıtları tespit ettikten sonra, önce staging ortamında autoload bayrağını no yapmak mümkündür:

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'ornek_option_adi';

Ardından sitenin ilgili fonksiyonlarını test edin. Her şey normal çalışıyorsa, canlıya uygulayabilirsiniz. Ancak tekrar vurgulayalım: Ne yaptığınıza emin değilseniz, çekirdek ve kritik ayarların autoload bayrağı ile oynamayın.

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

add_option ve update_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, uzun vadede sitenizin performansını doğrudan korur.

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örevlerinizi düzenli aralıklarla gözden geçirin.
• Çok sık tetiklenen görevleri azaltın, gerekirse gerçek cron job ile zamanlayın.

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.)

wp_options sorgularını da kapsayacak şekilde, WordPress nesne önbelleğini kalıcı hale getirmek (Redis, Memcached vb) performansa ciddi katkı sağlar. Özellikle:

• Yüksek trafikli sitelerde tekrar eden option sorgularının maliyetini düşürür.
• wp_options şişmiş olsa bile, doğru yapılandırılmış bir Redis ile bu etkiyi bir miktar sönümleyebilirsiniz (yine de temizlik şart).

Kalıcı cache dünyasına giriş yapmak için Redis cache performans rehberimize göz atabilir, sonrasında DCHost üzerinde Redis destekli VPS veya özel çözümlerle sitenizi daha da hızlandırabilirsiniz.

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ılarında Using where; Using index gibi notları görmeniz genelde iyidir. Aksi durumda, özel indeks ihtiyaçları olup olmadığını değerlendirmek gerekebilir.

MySQL tarafında ise özellikle aşağıdaki parametreler, yoğun WordPress kurulumlarında etkili olur:

• innodb_buffer_pool_size
• innodb_log_file_size
• query_cache (yeni sürümlerde kaldırıldığı için alternatif mekanizmalar)

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 ve autoload şişmesi doğrudan ilk sorgu süresini uzattığı için, TTFB üzerinde net bir etki yaratır. Sunucu tarafında PHP-FPM, OPcache, Redis ve doğru MySQL ayarları ile ince ayar yaparken, veritabanı katmanında bu tabloyu temizlemek çarpan etkisi yaratır. Yani:

• Hem PHP tarafında daha az bellek kullanırsınız,
• Hem MySQL daha az veri okur,
• Hem de üstüne bir de HTTP/2, HTTP/3, CDN gibi ek iyileştirmelerle siteyi gözle görülür şekilde hızlandırırsınız.

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ı

Tabii ki tek başına veritabanı temizliği, kaynak olarak çok zayıf bir altyapıyı mucizevi şekilde kurtarmaz. wp_options ve autoload şişmesini kontrol altına aldıktan sonra, halen CPU veya RAM yetersizliği yaşıyorsanız, hosting planınızı gözden geçirmek gerekebilir. Bu aşamada:

• Mütevazı WordPress siteleri için performanslı paylaşımlı hosting paketleri,
• Daha ciddi trafik alan veya WooCommerce kullanan projeler için ise kaynakları garanti edilmiş VPS ve dedicated çözümler

tercih etmek, uzun vadeli stabilite açısından kritik önem taşır. DCHost olarak WordPress odaklı paylaşımlı hosting, NVMe altyapılı VPS ve dedicated sunucu seçenekleri ile, wp_options optimizasyonu gibi uygulamaların etkisini tam anlamıyla hissedebileceğiniz bir zemin sunuyoruz.

Uzun Vadeli Bakım: wp_options Tablosunu Formda Tutmak

Düzenli Kontrol ve Otomasyon

wp_options temizliğini bir kez yapıp bırakmak yerine, bunu düzenli bakım rutininizin parçası haline getirmenizi öneriyoruz. Örneğin:

• 3 ayda bir autoload toplam boyutunu ölçün.
• Yılda en az bir kez transient ve kullanmadığınız eklenti ayarlarını gözden geçirin.
• Yeni eklediğiniz her büyük eklentiden sonra wp_options tablosundaki değişimi takip edin.

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, tek başına veritabanı veya tek başına sunucu ayarı ile çö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ı, altyapıyı izler, darboğazları raporlar ve iyileştirme önerileri sunar.

DCHost tarafında müşterilerle çalışırken en çok değer kattığımız noktalardan biri de tam olarak bu koordinasyon: Uygulama, veritabanı ve sunucu katmanlarını birlikte ele alan bir yaklaşım.

Sonuç: wp_options Temizliği ile WordPress Sitenize Derin Nefes Aldırın

Özetlemek gerekirse, WordPress veritabanı optimizasyonu deyince akla ilk gelmesi gereken yerlerden biri wp_options tablosu ve autoload kayıtları. Bu tablo yıllarca hiç dokunulmadan bırakıldığında, kaldırılmış eklentilerin artıkları, süresi geçmiş transient veriler, log/istatistik kayıtları ve yanlış işaretlenmiş autoload değerleriyle dolup taşıyor. Sonuçta hem sunucu kaynaklarınız gereksiz tüketiliyor hem de ziyaretçileriniz yavaş bir site deneyimi yaşıyor.

Bu rehberde; wp_options yapısını tanımaktan başlayarak, güvenli temizlik adımlarını, autoload şişmesini nasıl tespit edip azaltacağınızı ve gelecekte bu sorunun tekrar etmemesi için geliştirici ve sistem düzeyinde neler yapmanız gerektiğini detaylandırdık. Şimdi sırada bunları uygulamaya koymak var. Önce sağlam bir yedek alın, mümkünse staging ortamında adımları deneyin, ardından canlı sitenizi adım adım optimize edin.

Eğer DCHost üzerinde barındırdığınız bir WordPress siteniz varsa veya projelerinizi daha performanslı bir altyapıya taşımayı düşünüyorsanız, ekibimiz wp_options ve veritabanı optimizasyonu dahil olmak üzere sunucu, veritabanı ve uygulama katmanında size destek olmaya hazır. Daha hızlı, daha stabil ve ölçeklenebilir bir WordPress için bizimle iletişime geçebilirsiniz.