WordPress wp_postmeta Tablosu Neden Büyür? Güvenli Temizlik Rehberi

wp_postmeta tablonuz büyükse, bunun nedeni çoğunlukla birkaç meta anahtarının büyük olmasıdır. Sorun neredeyse hiçbir zaman “WordPress’in kendisi” değildir. Temizlik rehberlerinin ilk anlattığı sahipsiz satırlar da çoğu zaman asıl neden çıkmaz. Önce anahtarları bulun. Sorgu bir saniye sürer ve karşınızdakinin bir sayfa oluşturucu mu, bir mağaza mı, bir ortam kütüphanesi mi, yoksa iki yıl önce kaldırdığınız bir eklenti mi olduğunu size söyler.

Her birinin cevabı farklıdır ve bunların yalnızca bir kısmı silmektir.

Temizlemeden önce ölçün

İki sorguya ihtiyacınız var ve ikisi de yalnızca okur. Natro ya da Turhost gibi cPanel kullanan bir hostingdeyseniz, bunları cPanel’deki phpMyAdmin’de çalıştırırsınız. cPanel’de Veritabanları(Databases) bölümündeki phpMyAdminsimgesini açın. phpMyAdmin’de solda veritabanınızı seçin, SQLsekmesini açın, sorguyu yapıştırın ve Gitdüğmesine basın.

Önce tablo önekinizi kontrol edin. wp-config.phpdosyanızda $table_prefixolarak yazılıdır ve çoğu zaman wp_değildir. Bu yazıdaki tüm sorgular wp_kullanır; kendi önekinizi yazın.

Tablo ne kadar büyük ve bunun ne kadarı boş alan?

SELECT table_name,
       ROUND(data_length / 1048576, 1)  AS veri_mb,
       ROUND(index_length / 1048576, 1) AS indeks_mb,
       ROUND(data_free / 1048576, 1)    AS bos_mb,
       table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'wp_postmeta';

InnoDB tablolarında table_rowsbir tahmindir; bunu ölçeği görmek için kullanın, önce-sonra karşılaştırmanız için değil.

Alanı hangi anahtarlar kaplıyor?

SELECT meta_key,
       COUNT(*)                                    AS satir,
       ROUND(SUM(LENGTH(meta_value)) / 1048576, 2) AS deger_mb
FROM wp_postmeta
GROUP BY meta_key
ORDER BY deger_mb DESC
LIMIT 25;

İlk beş anahtarınızı satır sayısı ve boyutuyla not edin; sonunda bu listeyle karşılaştıracaksınız.

Her satır 0.00 gösteriyorsa bu da bir yanıttır, çünkü yeriniz wp_postmetaiçinde değildir. Bu yazının küçük test sitesinde 136 satır vardı ve her anahtar yuvarlanınca 0.00 MB çıktı.

En ağır anahtarlar genellikle hangileri?

Anahtarın öneki, onu kimin yazdığını size söyler. Başındaki alt çizgi onu özel alanlar kutunuzdan gizler, ama önemsiz olduğu anlamına gelmez.

En büyük anahtarınız bir sayfa oluşturucuya aitse, tablonuz sayfalarınız büyük olduğu için büyüktür ve silmek bunu çözmez, ama revizyonları azaltmak çözebilir. _oembed_*en üstteyse önbelleği güvenle temizleyebilirsiniz. Tanımadığınız bir anahtarsa, dokunmadan önce artık anahtarlar bölümünü okuyun.

WooCommerce’in siparişlerinizi nerede tuttuğunu WooCommerce› Ayarlar› Gelişmiş› Özellikleraltında, “Sipariş verisi depolama” satırında görürsünüz. Test sitesinde WooCommerce 11.2.1 ile: – WordPress gönderileri depolama (eski)seçiliyken bir sipariş wp_postmetatablosuna 25 satır yazdı, bunların altısı _billing_*idi; – Yüksek performanslı sipariş depolamaseçiliyken yeni bir sipariş hiç satır yazmadı; adresi wc_order_addressestablosuna gitti.

Ürünler meta verilerini her iki durumda da wp_postmetaiçinde tutar. Yeni depolamaya geçiş eski siparişin satırlarını yerinde bıraktı ve WooCommerce o siparişi temizlenecekler arasında gösterdi.

Mağazanız varsa.Mağazanız siparişleri hâlâ WordPress yazıları olarak saklıyorsa (WooCommerce ayarı: “WordPress gönderileri depolama (eski)”), _billing_*ve _customer_ip_addressgibi satırlar müşterilerinizin adını, adresini ve IP adresini tutar. Bunlar KVKK kapsamında kişisel verilerdir. Bir temizlik sırasında gelişigüzel silmeyin; saklama yükümlülüğünüzün gerektirdiğinden uzun süre de tutmayın. Bu karar veritabanı bakımının değil, veri koruma ve muhasebe düzeninizin işidir.

Sahipsiz satırlar: yazısı silinmiş metalar

Sahipsiz satırın post_iddeğeri artık wp_poststablosunda yoktur. WordPress bunları kendiliğinden üretmez, çünkü bir yazıyı sildiğinizde wp_delete_post()o yazının metasını da birlikte siler. Sahipsiz satırlar, birinin SQL ile sildiği yazılardan, yarıda kalan içe aktarmalardan ve kendi yazı türlerini yanlış silen eklentilerden gelir.

Sahipsiz satırınız olduğunu varsaymadan önce sayın:

SELECT COUNT(*) AS sahipsiz_satir,
       ROUND(SUM(LENGTH(pm.meta_value)) / 1048576, 2) AS sahipsiz_mb
FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;

Sonuç birkaç yüz satır ve bir megabaytın küçük bir kısmıysa sorununuz bu değildir; isterseniz temizleyin, ama anahtar listenize geri dönün. Tablonun büyük bir bölümüyse nedeninizi buldunuz.

Diğer meta tablolarını da kontrol etmek isterseniz, WordPress’te sahipsiz metadata kayıtları nasıl bulunuryazısı sizi adım adım götürür.

Revizyonların da metası vardır

Kaydettiğiniz her revizyon, wp_poststablosunda post_type = 'revision'olan bir satırdır. Sayfa oluşturucular bu revizyonların çoğuna düzen verilerinin bir kopyasını bağlar; sayfanızın 60 revizyonu varsa, 60 tane _elementor_datakopyası taşıyabilir.

Bir şey silmeden önce yazı başına sayın:

SELECT p.post_parent, COUNT(*) AS revizyon
FROM wp_posts p
WHERE p.post_type = 'revision'
GROUP BY p.post_parent
ORDER BY revizyon DESC
LIMIT 10;

Revizyonlarınızı WordPress, bir eklenti ya da WP-CLI ile silin; çıplak bir DELETE FROM wp_postsile değil. WordPress yolu metalarını da birlikte kaldırır, SQL yolu ise o metaları sahipsiz satır olarak geride bırakır ve siz bir önceki bölüme geri dönersiniz.

Büyümeyi durdurmak için wp-config.phpdosyanıza bir sınır koyun:

define( 'WP_POST_REVISIONS', 10 );

Yöntemin tamamını eski WordPress yazı revizyonları güvenle nasıl siliniryazısında bulursunuz.

Kaldırılan eklentilerin bıraktığı anahtarlar

Canınızın yanabileceği yer burası. Tanımadığınız bir anahtar çöp gibi görünür, ama bazen hâlâ kullandığınız bir şeye aittir: bir tema ayarına, functions.phpdosyanızdaki bir kod parçasına ya da adı anahtarla hiç ilgisi olmayan bir eklentiye.

Bir anahtarı silmeden önce üç şeyi netleştirin:

1. Onu kim yazdı.Anahtarın adını kurulu kodunuzda arayın. WP-CLI ya da kabuk erişiminiz varsa: grep -r "meta_anahtariniz" wp-content/. wp-contentiçinde sonuç çıkmıyorsa, onu okuyan etkin bir şey büyük olasılıkla kalmamıştır.
2. Onu hiçbir şeyin okumadığını.Artık kullanmadığınız bir eklentide çıkan sonuç sorun değildir; etkin temanızda ya da bir must-use eklentisinde çıkan sonuç ise “dur” demektir.
3. Kaç yazıda bulunduğunu.Yazılarınızın hepsinde bulunan anahtar bir ayardır; 2019’dan kalma on iki yazıda bulunan anahtar ise bir artıktır.

Bir eklentiyi devre dışı bırakmak metasını silmez. Eklentiler ekranından sildiğinizde, varsa kaldırma rutini çalışır, ama birçok eklentinin böyle bir rutini yoktur.

Tek bir anahtarı yan etki olmadan silmek

Önce bir veritabanı yedeği alın ve geri yükleyebildiğinizden emin olun; buradaki diğer her hatayı geri alınabilir yapan adım budur. Yedeği nasıl alıp doğrulayacağınızı WordPress veritabanını yedekleme ve SQL dışa aktarımını doğrulamayazısı gösterir.

Sonra anahtar anahtar ilerleyin. SELECTsorgunuzu çalıştırıp sayıyı okuyun, ardından tam olarak aynı WHEREile DELETEsorgunuzu çalıştırın:

SELECT COUNT(*) FROM wp_postmeta WHERE meta_key = 'eski_eklenti_anahtari';

DELETE FROM wp_postmeta WHERE meta_key = 'eski_eklenti_anahtari' LIMIT 5000;

DELETEsorgusunu 0 satır etkilenene kadar tekrarlayın. LIMITher sorguyu kısa tutar; böylece hostinginizin sorgu zaman aşımı onu yarıda kesmez. Uzun bir çalışma yine de durursa veritabanı temizliği takılıyor veya zaman aşımına uğruyorsayazısına bakın.

Önbelleğe alınmış gömmeler için liste yerine bir kalıp kullanın:

DELETE FROM wp_postmeta WHERE meta_key LIKE '\_oembed\_%' LIMIT 5000;

Ters eğik çizgilere ihtiyacınız var, çünkü LIKEiçinde kaçışsız alt çizgi herhangi bir tek karakterle eşleşir; '_oembed_%'kalıbı kastetmediğiniz anahtarları da yakalar.

Tablo diskte neden küçülmez?

Büyük bir silmeden sonra veri boyutunun çoğu zaman aynı kaldığını görürsünüz. InnoDB boşalan sayfaları dosya sisteminize geri vermek yerine yeniden kullanmak için tutar. Yukarıdaki ilk sorgu bunları size bos_mbolarak gösterir.

OPTIMIZE TABLE wp_postmeta;tabloyu yeniden kurar ve sunucunuz her tabloyu kendi dosyasında tutuyorsa bu alanı geri verir; güncel MySQL ve MariaDB’de varsayılan budur. Büyük bir tabloda yeniden kurma zaman alır ve yazma işlemlerini kilitleyebilir; bunu sitenizin sakin bir saatinde yapın. Ayrıntıları WordPress veritabanı tabloları güvenle nasıl optimize ediliryazısında bulursunuz.

Her temizlikten sonra optimize etmeniz gerekmez, çünkü tablodaki boş alanı sonraki kayıtlarınız yeniden kullanır. Bu alan, diski geri almanız gerektiğinde önemlidir; örneğin disk dolduğu için yedeğiniz tamamlanmıyorsa.

Doğrulama

Temizliğiniz, sayılar değiştiğinde ve siteniz değişmediğinde bitmiştir.

Asıl önemli satır sonuncusudur, çünkü doğru satırları silen bir temizlik tek başına hiçbir şey kanıtlamaz. Yanlış satırlara da dokunmamış olması gerekir; bunu size yalnızca dokunmadığınız bir anahtarın önce-sonra sayısı gösterir.

Test sitesinde dördüncü satır iki seferde de tuttu. Veritabanı Temizleyici çalıştıktan sonra dokunulmayan anahtar 7 satırda, ters bölü işaretsiz bir kalıbın da yakalayacağı tuzak anahtar 1 satırda kaldı. Yukarıdaki elle DELETE, yazıldığı gibi girildiğinde 3 satır sildi; dokunulmayan anahtar 14’te, tuzak anahtar 2’de kaldı. Ters bölü işaretleri olmadan aynı kalıp, tuzak anahtarlar dahil 5 satır yakaladı.

AIOWS nasıl yardımcı olur?

AIOWS Veritabanı Temizleyici

Veritabanı Temizleyici bu yazının rutin kısmını sizden alır; dikkatinizi gerektiren kısma vaktiniz kalır.

Karar gerektirmeyen silmeleri yapar.On bir görevinden ikisi bu yazıdaki güvenli silmelerdir. Sahipsiz Yazı Metaları, yazısı artık bulunmayan wp_postmetasatırlarını siler, başka hiçbir şeyi değil. oEmbed Önbelleği _oembed_anahtarlarını alt çizgisi kaçışlı olarak siler; yukarıdaki LIKEtuzağına düşmezsiniz. Yazı Revizyonları, WordPress’in kendi işleviyle siler; her revizyonun metası da birlikte gider. İsterseniz her yazının en yeni revizyonlarını korur. Aynı listede yedi günden eski otomatik taslaklar, çöpteki yazılar ve yorumlar, spam yorumlar, süresi dolmuş transient kayıtları ve sahipsiz yorum metaları da vardır; hepsini tek ekrandan, kendi sayılarıyla görürsünüz.

Önce sayıyı gösterir.Her görev kaç satır kaldıracağını, silmenin kendisiyle aynı koşullarla sayıp size gösterir ve kaldıracak bir şeyi olmayan görevi seçemezsiniz. Sahipsiz metalar silinmeden önce onay penceresi, en çok sahipsiz satırı olan anahtarları ve işaret ettikleri yazı kimliklerini listeler. Bu, sahipsiz satırların ne olduğuna son bakışınızdır.

Her seferinde önce yedek alır.Her temizlik, dokunacağı tabloların yedeğiyle başlar ve yedek yazılamazsa hiçbir şey silinmez.

Optimizasyonu ayrı tutar.Tabloları Optimize Et ayrı bir düğmedir; temizliğinizi yapar, sayılarınızı karşılaştırır, disk alanını istediğiniz zaman geri alırsınız.

Sahipsiz yazı metaları için onay penceresi kelimesi kelimesine şuydu:

Bu işlem önce bir veritabanı yedeği oluşturur, ardından seçilen öğeleri kalıcı olarak siler. Emin misiniz?

Silinecek sahipsiz yazı meta satırları, anahtara göre:
orphan_test_0 ×17
orphan_test_1 ×17
orphan_test_2 ×16
yazı kimlikleri 100.018–100.022, 5 nesne

Sınırları açıkça şöyle. Canlı yazılarınızın hangi meta anahtarlarının artık olduğuna karar vermez. Kaldırılmış eklentilerin anahtarları, yinelenen satırlar ve sahipsiz terim ya da kullanıcı metaları görevleri arasında yoktur; bunlar artık anahtarlar bölümündeki gibi, anahtar anahtar sizin işinizdir. Çöpteki ortam dosyalarını silmez, çünkü veritabanı yedeği dosyaları geri getiremez; ortam kütüphanesinin çöpünü kendiniz boşaltırsınız. Tablonuzun neden büyüdüğünü de size söylemez. Bunu yazının başındaki anahtar sorgusu söyler ve her araçtan önce çalıştırmaya değer.

AIOWS Veritabanı Temizleyici’yi inceleyinAIOWS planlarını karşılaştırın

Sık sorulanlar

500 MB’lık bir wp_postmeta tablosu sorun mudur?Tek başına değil. Bu tabloyu okuyan sorgularınız yavaşladığında ya da yedekleriniz ve diskiniz zorlandığında önem kazanır. Anahtar listesi, boyutun ihtiyacınız olan içerik mi yoksa atabileceğiniz veri mi olduğunu gösterir.

Alt çizgiyle başlayan tüm anahtarları silebilir miyim?Hayır. Alt çizgi yalnızca anahtarı özel alanlar kutunuzdan gizler. Görselleriniz, sayfa düzenleriniz ve mağaza verileriniz bu anahtarlarda durur.

Sahipsiz metaları silmek bir şeyi bozar mı?Sorgunuz yukarıdaki gibi wp_postsile birleştiriliyorsa hayır. Sahipsiz satır hiçbir yazıya ait değildir; siteniz onu hiçbir yerde gösteremez.

Temizlikten sonra tablo neden aynı boyutta?InnoDB boşalan alanı dosyanın içinde tutar. OPTIMIZE TABLEonu geri verir. Tablo diskte neden küçülmezbölümüne bakın.

Büyük bir wp_postmeta tablosu sitemi yavaşlatır mı?Meta değerine göre süzen sorgularınızı yavaşlatabilir; bazı mağaza ve arama sorguları gibi. Önbellekten sunduğunuz sayfaları etkilemez. Bunu varsaymadan önce ölçün.

Kaynaklar

• Post Meta — WordPress Geliştirici Kaynakları (Eklenti El Kitabı)
• wp_delete_post()— WordPress Geliştirici Kaynakları
• Revizyonlar — WordPress Belgeleri
• OPTIMIZE TABLE — MySQL 8.0 Başvuru Kılavuzu