WordPress veritabanı optimizasyonu, gereksiz kayıtları rastgele silmekten çok, hangi sorgu ve tablonun kaynak tükettiğini ölçüp uygun düzeltmeyi yapmaktır. Bir bakım eklentisinin “Optimize” düğmesi bazen alanı düzenler; fakat yavaşlığın nedeni büyük görseller, ağır bir eklenti, zayıf barındırma veya önbellek eksikliği ise beklenen hız artışını sağlamaz. Güvenli bir çalışma, başlangıç ölçümü ve geri yüklenebilir yedekle başlar; değişiklikten sonra aynı ölçüm tekrarlanır.
Bu rehberde WordPress tablolarını, otomatik yüklenen seçenekleri, revizyonları, geçici kayıtları ve yavaş sorguları birbirinden ayıracağız. Örnekler genel yön verir; tablo önekiniz ve eklenti tablolarınız farklı olabilir. Üretim veritabanında kopyala yapıştır ile toplu silme yapmadan önce test ortamı ve yedek kullanın.
Veritabanı WordPress’te ne saklar?
WordPress içerik, kullanıcı, ayar, yorum ve ilişki bilgilerini veritabanında tutar. wp_posts yazı ve sayfa yanında revizyon, ek dosya kaydı ve bazı özel içerik türlerini de barındırır. wp_postmeta içeriklere bağlı ek alanları saklar. wp_options site ve eklenti seçeneklerini taşır. Bunlara kullanıcı, yorum, terim ve ilişki tabloları eklenir. Kurulum sırasında belirlenen tablo öneki wp_ olmak zorunda değildir; kendi sitenizde gerçek adı doğrulayın.
Bir tablonun büyük olması tek başına problem değildir. Yayın arşivi geniş bir sitede posts tablosunun büyümesi beklenir. Önemli olan, tablonun boyutunun kullanım amacıyla uyumlu olup olmadığı ve ilgili sorguların gereksiz gecikme yaratıp yaratmadığıdır. Örneğin küçük bir blogda çok büyük bir seçenek değeri her istekte yükleniyorsa bu anlamlı bir inceleme konusudur. Öte yandan çok sayıda ürün içeren mağazada ürün meta verisinin fazla olması şaşırtıcı olmayabilir.
“Veritabanını küçültmek” ve “siteyi hızlandırmak” ayrı hedeflerdir. Eski logları temizlemek disk alanı kazandırabilir ama sayfa yanıt süresini değiştirmeyebilir. Doğru indeks ya da önbellek, fazla kayıt silmeden performansı iyileştirebilir. Bu yüzden başarı ölçütünü baştan yazın: disk kullanımı mı, yönetim ekranı açılma süresi mi, 95. yüzdelik sorgu süresi mi, yoksa ziyaretçinin hissettiği sayfa hızı mı?
İlk ölçüm: sorunun yeri nerede?
Önce etkilenen ekranları listeleyin. Yalnızca yönetim paneli mi yavaş, yoksa herkese açık sayfalar da mı? Sorun belirli bir yazıda, arama sayfasında, WooCommerce ödeme adımında veya medya kitaplığında mı yoğunlaşıyor? Aynı anda veritabanı bağlantı hataları görülüyorsa “temizlik” planından önce sunucu durumunu ve hata kayıtlarını inceleyin. Bağlantı limitine takılan bir hizmeti birkaç revizyon silerek iyileştiremezsiniz.
Hosting panelinde veritabanı boyutu, tablo büyüklüğü, PHP işçi kullanımı ve CPU/bellek sınırları bulunabilir. WordPress Site Sağlığı ekranı da bazı çevresel uyarıları verir. Teknik erişiminiz varsa yavaş sorgu günlüğü veya uygulama performans izlemesi üzerinden belirli sorguların süresini ölçün. Veritabanı yetkisi olmadan da tarayıcı geliştirici araçlarıyla sayfa yanıt süresini ve yönetim isteklerini not edebilirsiniz. Tek bir test yerine benzer koşullarda birkaç ölçüm alın.
Ölçüm sırasında eklenti puanını mutlak gerçek saymayın. Bir test aracı yüksek puan gösterirken yönetim paneli yine ağır olabilir. Tam sayfa önbelleği ziyaretçi tarafındaki veritabanı yükünü gizleyebilir; giriş yapmış editör farklı deneyim yaşar. Sorunun tam olarak hangi yolakta olduğunu ayırmak, gereksiz silme riskini azaltır.
Yedek ve staging olmadan temizliğe başlamayın
Veritabanı temizliği kayıt silme veya değiştirme içerebilir. Bu nedenle işlemden önce tam veritabanı yedeği alın ve geri yükleme yolunu test edin. Sadece eklentinin “yedek alındı” bildirimi yeterli değildir; dosyanın varlığını, tarihini ve erişimini doğrulayın. Dosyalar ile veritabanı arasındaki uyum gerekiyorsa tam site yedeği de alın. Ödeme veya üyelik gibi canlı veri değişen sitelerde test kopyasını üretimle karıştırmayın.
Staging ortamında eklenti ve SQL işlemlerini gerçek verinin uygun, güvenli kopyasıyla deneyin. Testten sonra örnek yazılar, kullanıcılar ve siparişler yerinde mi bakın. Özellikle WooCommerce mağazasında “eski kayıt” sanılan verinin rapor veya müşteri ilişkisi için gerekli olabileceğini unutmayın. Staging site rehberimiz üretimden ayrı ortamın kurulmasını anlatır.
Otomatik yüklenen seçenekleri nasıl incelersiniz?
wp_options tablosundaki bazı seçenekler her istekte otomatik yüklenir. Tema ve eklenti ayarlarının bir kısmı burada bulunur. WordPress’in performans belgeleri, çok büyük otomatik yüklenen toplam verinin siteyi yavaşlatabileceğini anlatır. Site Sağlığı, toplam boyut varsayılan eşiği aştığında uyarı verebilir. Bu uyarı, listedeki her seçeneği silmeniz gerektiği anlamına gelmez; hangi değerin neye ait olduğunu araştırmanız gerekir.
Önce Site Sağlığı bölümünde otomatik yüklenen seçenek uyarısı var mı bakın. Varsa toplam boyutu ve en büyük seçenekleri güvenilir bir araç veya hosting desteğiyle listeleyin. Her seçenek için sahibi olan eklentiyi, hâlâ kullanılıp kullanılmadığını, değerin her istekte gerekli olup olmadığını ve kaldırılırsa nasıl geri alınacağını belirleyin. Kullanılan ödeme, oturum veya tema ayarını yanlışlıkla otomatik yüklemeden çıkarmak ya da silmek bozuk sayfa oluşturabilir.
Özellikle eski eklentiden kalmış büyük veri dikkat çekebilir. Ancak “eski ad taşıyor” diye doğrudan silmeyin. Eklenti aktifse değer kullanılabilir; artık aktif olmayan bir eklentinin ayarı da geçiş veya geri dönüş için bilinçli saklanmış olabilir. Önce sahibini belirleyin, yedekleyin ve staging ortamında bir değişiklik uygulayın. WordPress API’si, seçeneklerin otomatik yükleme davranışını değerini silmeden değiştirmek için yöntemler sunar; bu geliştirici düzeyindeki işlemi yetkin ekibe bırakın.
Geliştirici kendi eklentisini yazıyorsa büyük ve nadiren kullanılan veriyi varsayılan otomatik yüklemeye bırakmamalıdır. Ayar kaydetme API’sinde uygun seçenekle bu davranış kontrol edilebilir. Fakat çekirdek ayarları topluca değiştirmek bir optimizasyon stratejisi değildir. Beklenen faydayı, öncesi/sonrası sorgu ve yanıt süresiyle ölçün.
Revizyonlar, otomatik kayıtlar ve taslaklar
İçerik revizyonları wp_posts tablosunda geçmiş sürüm olarak tutulur. Sık düzenlenen yazılarda sayıları artabilir. WordPress, WP_POST_REVISIONS ayarıyla gelecekte tutulacak normal revizyon sayısını sınırlandırmaya izin verir. Bu ayarın nasıl çalıştığını ve otomatik kayıt farkını WordPress revizyonları rehberinde adım adım anlattık.
Revizyon temizliği için önce hangi yazıların geçmişe ihtiyaç duyduğunu belirleyin. Eski sürümleri düzenli kullanan editoryal ekip için körlemesine toplu silme kötü bir takastır. Otomatik kaydı, yayımlanmış yazı ana kaydını ve çöp kutusundaki içeriği revizyonla karıştırmayın. Bakım aracındaki her kategori farklı sonuç doğurur. Yedek üzerinde birkaç örnek yazıyı geri yükleme provasından geçirin.
Revizyon sayısını azaltmak, kullanılan toplam disk alanını etkileyebilir; fakat büyük görsellerin kapladığı alan veya yavaş sorguların nedeni ayrı olabilir. Temizleme işlemini performans iyileştirmesi olarak raporlayacaksanız gerçek farkı ölçün. Bazı veritabanı motorlarında silinen kayıtların kapladığı fiziksel alan hemen küçülmez, yeni kayıtlar için yeniden kullanılabilir. Bu davranışı sunucunuzun veritabanı yapılandırması belirler.
Geçici kayıtlar ve önbellek verileri
WordPress Transients API, geçici değerlerin belirli süreyle saklanmasına izin verir. Depolama yöntemi ortamın nesne önbelleği yapılandırmasına göre veritabanı veya başka bir katman olabilir. Süresi geçmiş bir transient ile aktif geçici veriyi aynı saymayın. Bakım araçları “expired transients” gibi daha dar bir seçenek sunuyorsa kapsamı inceleyin. Aktif transient’ları topluca temizlemek ilk istekte yoğun yeniden üretim ve dış API çağrıları başlatabilir.
Geçici kayıtların çoğalması, bir eklentinin her işlemde benzersiz anahtar açması veya temizlik zamanlamasının çalışmaması gibi başka bir sorunun belirtisi olabilir. Sorunun kaynağını düzeltmeden tekrar tekrar silmek kalıcı çözüm olmaz. WordPress cron sistemini ve sunucu görevlerini kontrol etmek gerekebilir; fakat görevleri körlemesine açıp kapatmayın.
Eklenti tablolarını değerlendirirken
Bir eklenti özel tablo oluşturmuşsa kaldırıldıktan sonra bile tablo kalabilir. Önce tablo adından sahibi olan eklentiyi belirleyin, eklentinin hâlâ kullanımda olup olmadığını ve kendi kaldırma prosedürünü okuyun. Örneğin güvenlik günlükleri, sipariş analitiği veya form kayıtları arşivleme ve saklama politikası gerektirebilir. Tablonun büyük olması, gereksiz olduğu kanıtı değildir.
Bir özel tabloyu kaldırmak yerine saklama süresi kısaltılabilir, eski kayıtlar arşivlenebilir veya eklentinin resmi temizleme aracı kullanılabilir. Eklentinin ilişkili meta kayıtlarını ne yaptığına bakın. Canlı sistemde elle tablo düşürme işlemi, bir sonraki güncellemede beklenmedik hata doğurabilir. Staging kopyasında eklentinin temel akışlarını test etmeden üretimde değişiklik yapmayın.
Yavaş sorgu nasıl bulunur?
Sorun yalnızca belirli bir ekranda görünüyorsa aynı ekranı giriş yapmış ve çıkış yapmış durumda karşılaştırın. Hangi isteğin ne kadar sürdüğünü tarayıcı ağ sekmesinde not edin. Ardından sunucu ve veritabanı günlüklerinde aynı zaman aralığını inceleyin. Uygun tanılama araçları, sorgunun hangi eklenti veya işlev tarafından çağrıldığını gösterebilir. Üretimde ayrıntılı hata veya sorgu günlüğü açmanın performans ve gizlilik maliyeti olabileceği için süre ve kapsam sınırlı tutulmalıdır.
Yavaş sorgu görüldüğünde önce sorgunun neyi okumaya çalıştığını anlayın. Çok sayıda meta kaydı üzerinde filtre mi yapıyor, sıralama pahalı mı, yanlış tabloya tam tarama mı yapıyor? İndeks eklemek bazen yararlı olur, bazen yazma yükünü artırır veya hiçbir fark sağlamaz. Sorgu planını incelemeden genel “tüm tabloları optimize et” reçetesi vermek doğru değildir. Eklenti sorgusu sorunluysa eklenti güncellemesi veya yapılandırması daha uygun çözüm olabilir.
Ölçümü karşılaştırılabilir tutun. Önbellekli ve önbelleksiz ilk isteği birbirine karıştırmayın. Aynı sayfanın farklı ziyaretçi, dil veya ürün sayısıyla çalışması sorgu yükünü değiştirebilir. Ortalama sürenin yanında en yavaş örnekleri de kaydedin. Bir sorgu çok hızlı olsa bile saniyede binlerce kez çalışıyorsa toplam yük büyük olabilir; tek yavaş sorgu da yönetim ekranını kilitleyebilir.
Nesne önbelleği ve sayfa önbelleğinin rolü
Kalıcı nesne önbelleği, uygulamanın sık kullandığı verileri bellekte tutarak veritabanına tekrar tekrar gitmesini azaltabilir. Bu özellik barındırma ortamında destek gerektirir. Tam sayfa önbelleği ise oluşturulmuş sayfayı birçok ziyaretçiye yeniden sunar. İkisi farklı katmanlardır. WordPress’in performans belgeleri nesne önbelleğinin veritabanı yolculuklarını azaltabileceğini anlatır; ancak yanlış yapılandırılmış önbellek tutarsız içerik veya oturum sorunu yaratabilir.
Önce hangi önbelleğin zaten etkin olduğunu ve eklentinin aynı işi yapıp yapmadığını öğrenin. Birden çok önbellek eklentisini üst üste kurmak bakım karmaşasını artırır. Ödeme, sepet, hesap gibi kişiye özel sayfaları yanlışlıkla herkese açık önbelleğe almamak önemlidir. Değişiklikten sonra giriş yapmış ve çıkış yapmış ziyaretçi akışlarını deneyin. Önbellek kullanımı, yavaş sorgu kaynak kodunu iyileştirme ihtiyacını tamamen kaldırmaz.
OPTIMIZE TABLE komutu ne zaman düşünülür?
MySQL veya MariaDB’deki tablo bakım komutları, depolama motoruna ve ayarlara göre farklı sonuçlar verir. MariaDB belgelerinde OPTIMIZE TABLE belirli koşullarda kullanılmayan alanı geri kazandırma veya tabloyu yeniden düzenleme aracı olarak anlatılır. Büyük tabloda işlem sırasında ek disk alanı, kilit veya yük oluşturabileceği için üretimde rastgele çalıştırmayın. Özellikle paylaşımlı hostingde sağlayıcıdan bakım penceresi ve yöntem hakkında bilgi alın.
Önce gerçekten büyük miktarda kayıt silinmiş mi, alan kazanımı önemli mi ve dosya düzeni buna uygun mu inceleyin. Silinen alanın hemen diskte azalmaması her zaman başarısızlık değildir; veritabanı onu sonraki yazmalarda kullanabilir. Komutun sonucunu tablo boyutu, sorgu performansı ve sunucu sağlığı üzerinden ölçün. Bazı ortamlarda sağlayıcının yönetilen bakım aracı daha güvenli olabilir.
Adım adım güvenli optimizasyon planı
- Yavaş ekranı, zamanı ve kullanıcı türünü tanımlayın.
- Sunucu, PHP, veritabanı ve tarayıcı ölçümlerinden başlangıç değerlerini kaydedin.
- Tablo boyutlarını ve otomatik yüklenen seçenekleri inceleyin.
- Geri yüklenebilir veritabanı ve gerekirse tam site yedeği alın.
- Staging üzerinde tek bir aday düzeltmeyi uygulayın; örnek içerik akışlarını test edin.
- Canlıda uygun bakım penceresinde küçük kapsamla uygulayın.
- Aynı ölçümleri tekrarlayın; beklenen fark yoksa geri alın veya başka kök neden arayın.
Bu planın “tek değişiklik” ilkesi önemlidir. Revizyon, transient ve autoload değerlerini aynı anda değiştirirseniz hangi adımın yarar ya da sorun yarattığını göremezsiniz. Her adım için işlem tarihi, etkilenen tablo veya seçenek ve geri dönüş yolunu not edin. Böyle bir kayıt, ileride eklenti güncellemesi sonrası aynı sorunun yeniden çıkmasını anlamayı kolaylaştırır.
Üç farklı sorun, üç farklı çözüm
Yalnızca medya kitaplığı geç açılıyor
Görsellerin sayısı çok olsa bile önce ağ isteğinin durumunu ve PHP hata günlüğünü kontrol edin. Bir eklenti her medya öğesine ek sorgu çalıştırıyor veya uzak depolama bağlantısı yavaşlıyor olabilir. Genel veritabanı temizliği yerine bu ekranın sorgusunu ve isteğini düzeltmek gerekir. Ortam kitaplığı yavaşlığı rehberi bu ayrımı daha ayrıntılı ele alır.
Tüm sayfalarda ilk yanıt süresi yüksek
Sunucu kapasitesi, PHP işçi sayısı, autoload toplamı, nesne önbelleği ve eklenti sorguları birlikte incelenmelidir. Site Sağlığı uyarısını ve hosting kaynak grafiğini karşılaştırın. Aşırı autoload görüldüğünde yalnızca büyük seçenekleri sahiplerine göre araştırın. Hiç uyarı yoksa veritabanını suçlamak için başka kanıt gerekir. Testleri düşük ve yüksek trafik saatlerinde tekrarlayın.
Veritabanı diski doluyor
En büyük tabloları ölçün. Log, istatistik, revizyon veya geçici verinin hangisinin büyüdüğünü bulun. Saklama süresi ve yasal gereksinim varsa ona uyun. Silme sonrası fiziksel alanın hemen küçülmemesi olasılığını planlayın. Disk doluluğu acilse öncelik sistemin güvenli çalışmasını ve yedeğin alınmasını sağlamaktır; rastgele tablo düşürmek hizmet kesintisini artırabilir.
Sık sorulan sorular
WordPress veritabanı ne sıklıkla optimize edilmeli?
Sabit bir haftalık temizlik zorunluluğu yoktur. Sitenin yazı sayısı, eklenti yapısı ve trafik düzeyine göre düzenli ölçüm daha önemlidir. Kaydedilen veriler artıyor ve sorun yaratıyorsa saklama politikası uygulayın. Sürekli aynı geçici kayıtları silme ihtiyacı doğuyorsa onları üreten işlevi düzeltin. Takvimli bakım, yalnızca geri dönüş ve izleme süreciyle birlikte anlamlıdır.
Bakım eklentisi kurmak yeterli mi?
Hayır. Eklenti hangi kayıtları sildiğini gösterse de sorunun kök nedeni başka olabilir. Ayrıca bakım eklentisinin kendisi güncel ve güvenilir olmalı, işlem öncesi yedek bulunmalıdır. Her seçeneği işaretlemek yerine hedefle uyumlu dar kapsam belirleyin. Eklentiyi çalıştırdıktan sonra canlı iş akışını ve ölçümleri test edin.
Autoload uyarısı varsa hangi seçeneği silmeliyim?
Uyarı tek başına silme listesi vermez. En büyük değerleri çıkarıp her birinin hangi eklentiye veya çekirdek işlevine ait olduğunu saptayın. Bir değerin her istekte gerekli olup olmadığını geliştirici belgeleri ve staging testiyle anlayın. Aktif güvenlik, ödeme veya tema ayarını kaldırmak ciddi işlev kaybı yaratabilir. Gerekirse hosting veya geliştirici desteği alın.
Veritabanı optimizasyonu Google sıralamasını yükseltir mi?
Doğrudan sıralama garantisi vermez. Eğer yavaş sunucu yanıtının gerçek nedeni veritabanıysa ve düzeltme sayfa deneyimini iyileştirirse dolaylı bir fayda olabilir. Ancak arama performansını değerlendirirken içerik, teknik erişim ve kullanıcı niyeti gibi başka etkenleri de dikkate alın. “Optimize edildi” bildirimi yerine gerçek kullanıcı ve sunucu ölçümlerine bakın.
Sonuç
WordPress veritabanını güvenle iyileştirmek için tablo ve sorgu düzeyinde kanıt toplayın. Revizyon, transient, autoload ve eklenti tablolarını ayrı sorular olarak ele alın. Geri yüklenebilir yedek ve staging provası olmadan silme yapmayın. Sonuçları aynı yöntemle ölçüp fayda görülmeyen müdahaleleri yeniden değerlendirin. Böylece daha küçük bir veritabanından çok, sorunun nedenini anlayan sürdürülebilir bir bakım düzeni kurarsınız.
Kaynaklar: WordPress: Optimization, WordPress: Transients API, WordPress: autoload uyarı eşiği, MariaDB: OPTIMIZE TABLE.
