WooCommerce Yavaşladığında Veritabanını İncelemek
Kampanya sırasında ürün sayfalarının geç açılması, sepet güncellemelerinin uzaması veya ödeme adımının takılması tek başına MySQL arızasını göstermez. PHP süreçleri, eklentiler, harici ödeme servisleri ve veritabanı birlikte ölçülmelidir. Veritabanında darboğaz varsa InnoDB buffer pool, sorgu planları, indeksler ve kilit beklemeleri incelenecek başlıca alanlardır.
Bu kontrol listesi, WooCommerce için bellek bütçesini oluşturmayı, ürün ve sipariş tablolarını doğru ayırmayı ve slow query analizinden ölçülebilir değişikliklere geçmeyi anlatır. Örnekler bir müşteri projesinin sonuçları değildir. Ayarlara başlamadan MySQL veya MariaDB sürümünü, WooCommerce sürümünü ve etkin sipariş depolama yöntemini kaydedin; MySQL 8.0 ile 8.4 ayarları bile tamamen aynı varsayılanlara sahip değildir.
WooCommerce Trafiği Neden MySQL’de Düğümlenir?
Okuma-yazma dengesi: Sepetteki her tık bir izi bırakır
WooCommerce, ürün listelemeden sepete, kupondan ödemeye kadar farklı okuma ve yazma yükleri üretir. Katalog gezintisi genellikle okuma ağırlıklıyken ödeme işlemleri sipariş ve stok kayıtlarını günceller. Eklentiler bu akışa ek sorgular ve harici çağrılar katabilir. InnoDB’nin buffer pool, redo log ve flush davranışları bu yükün gecikmesini ve veri dayanıklılığını etkiler; yalnızca genel CPU grafiğiyle sorunun kaynağı belirlenemez.
Mesela şöyle düşün: Bir markette kasaların önüne kurulan minik el arabaları gibi, Buffer Pool da verileri belleğe yerleştiriyor. Arabalar doğru yerdeyse sıra hızlı akıyor. Ama arabalar hem çok küçük hem de yanlış yerdeyse, ürünler tekrardan raftan taşınmak zorunda kalıyor. Diskten getir-götür başlıyor ve kuyruk uzuyor.
Ölçmeden ayar olmaz: Küçük bir temel fotoğraf çek
Önce karşılaştırılabilir bir temel ölçüm alın: ürün gezintisi, sepete ekleme, ödeme ve yönetim raporları için istek sayısını, eşzamanlılığı, yanıt sürelerinin p95/p99 değerlerini ve hata oranını kaydedin. Aynı veri kümesi ve ısınmış önbelleklerle CPU, disk gecikmesi, bağlantı sayısı ve veritabanı sayaçlarını izleyin. Geçen haftanın aynı saati tek başına karşılaştırılabilir yük demek değildir; kampanya, eklenti, veri hacmi ve önbellek durumu değişmiş olabilir. Bir seferde bir değişiklik yapın ve uygulama sonucunu da tekrar ölçün.
Eğer altyapının enerjisini daha yukarı taşımak istiyorsan, sunucu tarafındaki bütünsel ayarları da hatırla. Bizim şu rehber, WordPress için sunucu tarafı optimizasyonunda neyi, ne zaman, nasıl ayarlamalısın, resmin tamamını görmek için güzel bir eşlikçi olur. Bir diğer tarafta, WooCommerce’in gerçekçi yüklerini tahmin etmek için kapsamlı kapasite planlama rehberine göz atmak, doğru miktarda kaynakla yola çıkmanı sağlar.
Buffer Pool: InnoDB’nin Nefesi Ne Kadar Uzun Olmalı?
Ne kadar RAM ayırmalı? “Yeterince büyük, ama aşırı değil” dengesi
Buffer Pool, InnoDB’nin en önemli belleği. Sık okunan sayfaları, indeksleri ve veri sayfalarını burada tutar. Mantık basit: Ne kadar çok veriyi RAM’de tutarsan, diske o kadar az uğrarsın. Ama her güzel şeyin bir dozu var. Tüm RAM’i MySQL’e vermek, sistemin nefesini keser. İşletim sistemi, PHP-FPM, Nginx/Apache, Redis veya arka plandaki diğer servisler de pay ister.
Sabit bir RAM yüzdesini her sunucuya uygulamayın. Örneğin 32 GB RAM’li ortak bir sunucuda PHP çalışanlarının tepe tüketimi, Redis, işletim sistemi ve MySQL’in buffer pool dışındaki bellek alanları da bütçeye dahildir. Veritabanının toplam veri ve indeks boyutu yalnızca envanterdir; yoğun saatlerde erişilen çalışma kümesini doğrudan ölçmez. Buffer pool’u kademeli değiştirin; ısınma sonrasında fiziksel okuma hızını, disk gecikmesini, boş belleği ve swap hareketini birlikte karşılaştırın.
Buffer Pool ayarlarını yaparken, MySQL’in InnoDB Buffer Pool dokümantasyonuna göz atmak akıl açar. Orada meselelerin özünü sade bir dille anlatırlar. Sen yine de formül ezberlemek yerine, kendi sitenin erişim desenine güven. Uzun açıklamalar veritabanındaki veri hacmini artırabilir; görsel dosyaları ise normalde veritabanında değil, dosya sisteminde veya nesne depolamada tutulur. Buffer Pool ihtiyacını asıl belirleyen, erişilen veri ve indeks sayfalarıdır.
Buffer Pool parçaları, arka plan temizlikçisi ve flush düzeni
MySQL 8.0 ve 8.4, innodb_buffer_pool_instances ve innodb_page_cleaners ayarlarını destekler; varsayılan hesapları sürüme göre değişir. MySQL 8.4’te temizleyici sayısı varsayılan olarak havuz örneği sayısına bağlıdır ve bu sayıyı aşmaz. Havuzu çekirdek sayısına eşitlemek yerine, yeterince büyük örnekler ve ölçülmüş kilit çekişmesi/flush yükü üzerinden değerlendirin. MariaDB’nin aynı adlı değişkenlerinin desteğini ayrıca kontrol edin; MySQL yapılandırmasını olduğu gibi taşımayın.
Flush ayarlarını, depolamanın ilan edilen en yüksek IOPS değerine göre seçmeyin. innodb_io_capacity ve üst sınırı, uygulamanın ön plandaki okumalarına ve yazmalarına pay bırakan sürdürülebilir arka plan yazma kapasitesini temsil etmelidir. innodb_flush_neighbors gibi ayarların yararı depolama türüne ve iş yüküne bağlıdır. Fiziksel okuma gecikmesi, bekleyen yazmalar ve kirli sayfa/checkpoint baskısı değişmeden yalnızca NVMe kullanılıyor diye değer artırmak uygun değildir.
Redo log: O son hamleyi güvenli saklama sanatı
Redo log, InnoDB’nin çökme sonrası kurtarmada kullandığı değişiklik kayıtlarını tutar. Yetersiz kapasite checkpoint baskısını ve yoğun flush işlemlerini artırabilir; daha büyük kapasite de disk alanı ve kurtarma süresi açısından değerlendirilmelidir. MySQL 8.0.30 ve sonrasında innodb_redo_log_capacity kullanılır. Önceki MySQL sürümlerinde kapasite innodb_log_file_size ve innodb_log_files_in_group ile belirlenirdi. MariaDB’nin redo yönetimi farklıdır. Mevcut log dosyalarını elle silerek boyut değiştirmeyin; sürümünüzün desteklediği yöntemi izleyin.
Siparişlerin kalıcılığını korumak için innodb_flush_log_at_trx_commit=1 temel tercihtir; binary log açıksa sync_binlog=1 ile birlikte değerlendirilir. 0 veya 2 kullanıldığında çökme türüne ve flush zamanlamasına göre onaylanmış işlemler kaybolabilir. UPS, RAID ve yedekler bu riski ortadan kaldırmaz; depolamanın flush isteklerini doğru uygulaması da gerekir. Performans sorununun çözümü olarak sipariş dayanıklılığını sessizce düşürmeyin.
Geçici tablolara küçük bir bakış: tmp_table_size ve dostları
Geçici tabloların bellek sınırları motor ve sürüme bağlıdır. MEMORY tabanlı dahili geçici tablolarda tmp_table_size ile max_heap_table_size değerlerinin küçüğü geçerlidir. MySQL 8.4’ün TempTable motorunda tmp_table_size tek tabloyu; temptable_max_ram ve temptable_max_mmap ortak kaynakları sınırlar. Bu kuralları bütün MySQL 8.0 alt sürümlerine veya MariaDB’ye taşımayın. Diskte geçici tablo oluşması tek başına hata değildir. Sorgu planını ve eşzamanlı bellek tüketimini incelemeden bu limitleri ya da oturum başına kullanılabilen sort_buffer_size/join_buffer_size alanlarını büyütmeyin.
İndeksleme: WooCommerce Tablolarında Gizli Kısayolları Açmak
wp_postmeta: kimlik araması ile değer aralığını ayırın
Ürünlerin ve varyasyonların birçok özel alanı wp_postmeta içinde bulunur. (post_id, meta_key) bileşiği, ürün kimliği ve alan anahtarıyla aramayı destekleyebilir; meta_value üzerindeki fiyat veya stok aralığını doğrudan indekslemez. Sayısal fiyat aralıkları için tam metin arama uygun bir çözüm değildir. WooCommerce’in desteklediği sorgularda wc_product_meta_lookup fiyat ve stok alanlarını sunar; kategori/görünürlük ilişkileri ise ilgili WordPress taksonomi tablolarıyla değerlendirilir. Önce mevcut indeksleri ve gerçek sorgunun EXPLAIN planını inceleyin. Özel eklenti sorgularını uygun veri erişim yoluna geçirmek kod değişikliği gerektirebilir.
Varsayımsal bir örnekte, küçük veri kümesinde hızlı görünen bir rapor gerçek veri hacminde farklı bir sorgu planıyla yavaşlayabilir. İlk adım sorgunun EXPLAIN planını incelemek, sonra mevcut indekslerin ve veri dağılımının bu planı neden oluşturduğunu değerlendirmektir. Bir indeks eklemek, ancak plan ve ölçümler bu ihtiyacı destekliyorsa sonraki adımdır.
Sipariş kayıtları, HPOS ve analiz tabloları
wc_order_stats ve wc_order_product_lookup WooCommerce analiz ve raporlama tablolarıdır; yönetim sipariş listesinin genel ana veri kaynağı sayılmaz. HPOS etkinse siparişin esas kayıtları wc_orders, wc_order_addresses, wc_order_operational_data ve wc_orders_meta tablolarındadır. Eski depolama yöntemi posts/postmeta kullanır; uyumluluk eşitlemesi açıkken iki küme bulunması ikisinin de esas kaynak olduğu anlamına gelmez. Tablo adlarının başına kurulumunuzun öneki gelir. İndeks önerisini, raporun veya sipariş ekranının gerçekten çalıştırdığı sorguya bağlayın.
Örneğin bir analiz sorgusu tek bir durum değerini ve tarih aralığını filtreliyorsa, (status, date_created_gmt) bileşiği incelenebilir; önce tarih aralığını kullanan ters sıra aynı miktarda daraltma sağlamayabilir. Bununla birlikte seçicilik, sıralama ve mevcut indeksler gerçek planı belirler. HPOS sipariş sorgularında zaten (type, status, date_created_gmt) gibi indeksler bulunabilir. wc_order_product_lookup şemasında order_id ve product_id indeksleri de bulunur. SHOW INDEX/SHOW CREATE TABLE ile kurulu sürümü görmeden bunları yeniden oluşturmayın.
Ürünler, varyasyonlar ve kategori ilişkileri
Kategori ve varyasyon sorguları wp_posts, wp_term_relationships, wp_postmeta ve sorguya göre ürün lookup tablolarını birleştirebilir. WordPress’in ilişki tablosunda (object_id, term_taxonomy_id) birincil anahtarı ve term_taxonomy_id indeksi zaten vardır; posts tablosunda da tür/durum/tarih ve ebeveyn indeksleri bulunur. Eksik varsayarak yenilerini eklemek yerine, veri dağılımını, join koşullarını ve plandaki satır tahminlerini inceleyin. Ürün lookup verisini yeniden oluşturmak eski veriyi onarabilir; HPOS’u etkinleştirmez ve eklenti SQL’ini otomatik değiştirmez.
İyi seçilmiş indeksler sorguların ihtiyaç duyduğu satırlara daha az iş yaparak erişmesini sağlayabilir. Gereksiz indeksler ise sipariş ve stok güncellemelerine ek yazma yükü getirir. Okuma yararı ile yazma maliyetini gerçek sorgular ve karşılaştırılabilir trafik üzerinden değerlendirin.
Slow Query Analizi: Sorunu Bulmanın Sakin Yolu
Slow query log: “Nerede takılıyoruz?” sorusunun dürüst cevabı
Slow query log için önce mevcut ayarları kaydedin, erişim izinlerini ve dosya alanını kontrol edin. Sorunlu dönemi temsil eden sınırlı bir yakalamada slow_query_log ve uygun long_query_time eşiği kullanılır. log_queries_not_using_indexes çok sayıda ucuz sorguyu da kaydedebilir; sürekli açmak yerine ihtiyaç varsa sınırlandırın. log_output=FILE yalnızca çıktı hedefini seçer, örnekleme yapmaz. GLOBAL long_query_time değişikliği mevcut bağlantıların oturum değerini değiştirmez; bağlantı havuzunu da hesaba katın. Yakalama sonunda önceki ayarları geri alın.
Loglar sorgu sabitleriyle müşteri verisi içerebilir. Dosyaları sınırlı erişimle tutun, saklama süresi ve rotasyon belirleyin; inceleme için aktarırken hassas değerleri ayıklayın. Eşiği çok düşürmek log hacmini ve ek yükü artırır. Önce kısa ve temsil gücü olan bir zaman aralığı seçin; iyileştirme sonrasındaki karşılaştırmayı benzer yükle yapın.
EXPLAIN ile sorgunun iç sesi
EXPLAIN, seçilen erişim yolunu, join sırasını, tahmini satırları ve sıralama ihtiyacını gösterir. Filtrelenen her sütuna ayrı indeks eklemek çözüm değildir; bileşik indeksin sol öneki, eşitlik/aralık koşulları ve ORDER BY birlikte değerlendirilir. MySQL EXPLAIN çıktısının açıklaması alanları yorumlamaya yardımcı olur. EXPLAIN ANALYZE MySQL 8.0.18’den itibaren sorguyu gerçekten çalıştırır; büyük veya veri değiştiren bir sorguya gelişigüzel uygulamayın. Önce temsilî verili test ortamında, kontrollü SELECT sorgularıyla kullanın. MariaDB’nin ANALYZE sözdizimi aynı değildir.
WHERE içinde tarih koşulunu önce yazmak, optimizer’ın önce onu uygulayacağını garanti etmez. Durum eşitliği ve yarı açık tarih aralığı gibi koşulları doğru ifade edin; join sırasını, kullanılan anahtarı, taranan satırları ve gerçek süreleri plandan okuyun. Her filesort diskte sıralama anlamına gelmez ve küçük sonuçlarda normal olabilir. Hedef, belirli bir plan etiketini yok etmekten çok, doğru sonucu daha az kaynakla üretmektir.
pt-query-digest ile kalabalığı özetlemek
Bir dönem geçtikten sonra elinde büyük bir slow log olur. Onu tek tek okumak yerine, pt-query-digest ile gruplamak harika bir kolaylık sağlar. Sorguları kalıplarına göre gruplayın; toplam süreyi çağrı sayısı, ortalama süre ve incelenen satırlarla birlikte değerlendirin. Buradan çıkan dersler, indeks düzeltmeleri veya sorgu iyileştirmeleri için doğrudan aksiyona dönüşür. Aracı merak ediyorsan, pt-query-digest hakkında özet bilgi işini görür.
İnceleme sıklığını kampanyalara, eklenti güncellemelerine ve görülen gecikmelere göre belirleyin. Sürekli ayrıntılı log tutmak yerine temel metrikleri izlemek ve ihtiyaç halinde sınırlı yakalama yapmak daha yönetilebilir bir süreç oluşturur. Bir sorguyu hızlandırdıktan sonra ödeme hata oranını ve yazma gecikmesini de kontrol edin.
Performance Schema ve sys schema ile hızlı bir bakış
Performance Schema sorgu kalıpları, kilit beklemeleri ve I/O hakkında toplu veri sunar; sys görünümleri bunu okumayı kolaylaştırır. İfade süresi CPU süresiyle aynı değildir. Sayısal sıralama için ham SUM_TIMER_WAIT veya uygun sys.x$statement_analysis alanları kullanılabilir; biçimlendirilmiş “ms/s” metinlerini sayısal süre gibi sıralamayın. Sayaçları tanımlı aralıklarla karşılaştırın ve toplama/timing ayarlarının açık olduğunu doğrulayın. Teşhis kaydı örnek sorgu metni de içerebildiği için erişimini sınırlandırın.
Kontrol Listesini Bir Değişiklik Planına Dönüştürmek
Varsayımsal bir mağazada ödeme gecikmesini inceleyen ekip önce geri yüklenebilir yedeği, sürümleri ve temel yük ölçümünü doğrular. Fiziksel okumalar ve bellek baskısı buffer pool değişikliğini destekliyorsa küçük bir artış test edilir. Checkpoint baskısı ayrı bir sorun gösteriyorsa redo kapasitesi kendi ölçümleriyle değerlendirilir. İki değişikliğin aynı anda yapılmaması, hangi adımın sonucu etkilediğini anlamayı kolaylaştırır.
Ardından kısa bir slow log yakalaması pt-query-digest ile gruplanır. En maliyetli sorguların planları ve mevcut indeksleri incelenir; yalnızca kanıtlanan bir ihtiyaç varsa aday indeks test ortamında oluşturulur. Büyük tabloda indeks yapımı disk alanı, I/O ve metadata kilidi gerektirebilir; “online” olması sıfır etki anlamına gelmez. Üretim değişikliği için uygun pencere, izleme ve geri dönüş adımı hazırlanır. Sonuçlar benzer yük altında yanıt süresi, hata oranı ve yazma maliyetiyle karşılaştırılır; önceden belirlenmiş bir hızlanma vaat edilmez.
İş akışı şu sırayı izler: yedek ve geri dönüşü doğrula, ölç, planı incele, gerekçeli tek değişikliği test et ve tekrar ölç. İyileşme görülmeyen bir indeksin yazma ve disk maliyetini de değerlendirin; “kontrol listesinde var” diye tutmayın. Mevcut indeksleri kaldırmadan diğer sorgulara etkisini ayrıca sınayın.
Bu arada, eğer arka tarafta önbelleği de doğru kurmak istersen, WooCommerce için kalıcı nesne önbelleği ve TTL ayarlarına dair şu pratik rehber çok işlev görüyor. Uygulama katmanındaki doğru önbellek, veritabanının yükünü hafifletip tuning hamlelerini daha etkili kılar.
Sunucu Tarafı Dokunuşları: Küçük Ayarlar, Büyük Sükûnet
Depolama gecikmesi ve bellek paylaşımı MySQL ayarlarının etkisini sınırlar. Doğrudan I/O, desteklenen işletim sistemi/dosya sistemi birleşiminde çift önbelleklemeyi azaltabilir; yalnızca SSD kullanılması belirli bir flush yöntemini zorunlu kılmaz. Yoğun swap hareketini bellek bütçesiyle azaltın; swap’i kapatmak yetersiz bellek durumunda süreçlerin sonlandırılma riskini artırabilir. THP veya başka çekirdek ayarlarını evrensel reçete olarak değiştirmeyin; sürüm belgeleri ve ölçülmüş gecikmeler üzerinden karar verin.
Bir diğer kritik konu, düzenli ve sağlıklı yedekleme. MySQL’i rahatlatırken veriyi asla riske atma. “Bir şey güncellemeden önce ben yedeği görmek istiyorum” alışkanlığı, uyku kalitesini bile artırır. Bu konuda kafanın bir köşesinde dursun diye, MySQL/MariaDB yedekleme stratejilerini derli toplu anlattığımız bir yazıyı bırakıyorum. Sen yine de tuning hamlelerinden önce, otomatik yedeklerin gerçekten çalıştığını test etmeden ilerleme.
Kaynak seçimi aşamasındaysan ve altyapıyı büyütmeyi düşünüyorsan, doğru VPS kaynaklarını seçme rehberi de güzel bir eşlikçi olur. CPU, RAM ve disk I/O dengesini birlikte değerlendirmek, bir katmandaki darboğazı başka bir katmanda gereksiz kaynak artırımıyla çözmeye çalışmayı önler.
WooCommerce İçin İnce Ayar: Adım Adım Yol ve Küçük Sırlar
Önce ölç, sonra ayarla
Buffer pool’u büyütmeden önce disk okumalarının ne zaman arttığını ve bellek baskısı olup olmadığını belirleyin. Innodb_buffer_pool_reads ile Innodb_buffer_pool_read_requests başlangıçtan beri biriken sayaçlardır; ömür boyu toplamları yerine aynı süre içindeki farklarını karşılaştırın. Isınma, toplu tarama ve trafik artışı da fiziksel okumaları artırabilir. Değişiklik sonrasında yalnızca hit oranını değil, uygulama gecikmesini ve hata oranını da izleyin.
İndeks eklerken, yazma maliyetini unutma
İndeksler sorguyu hızlandırabilir, ancak INSERT/UPDATE/DELETE işlemleri ve disk alanı için maliyet taşır. Sütun sırasını yalnızca “en seçici önce” kuralıyla seçmeyin: eşitlik koşulları, ilk aralık koşulu, sol önek kullanımı ve sıralama birlikte önemlidir. Önek indeksleri tam metin değerini kapsamayabilir. Var olan indeksleri ve tüm önemli sorgu yollarını ölçmeden yeni indeks eklemeyin veya eskiyi kaldırmayın.
Slow query analizi bir kez değil, rutin
Trafik, veri hacmi ve eklentiler değiştiğinde sorgu planları da değişebilir. Kampanya ve büyük güncellemelerden sonra temel metrikleri gözden geçirin; sapma varsa sınırlı slow log yakalamasıyla ayrıntıya inin. Donanım yükseltmesini, sorgu iyileştirmesiyle karşılaştırırken toplam kapasiteyi, maliyeti ve bakım sorumluluğunu birlikte değerlendirin.
Kodu da unutma
Bazen sorun veritabanında değil, sorguyu inşa eden kod satırlarında saklıdır. Gereksiz join, aceleye gelmiş bir LIKE koşulu, sayfalandırmanın yanlış uygulanması… Kod düzeltmelerinin etkisini aynı sorgu sonuçlarını ürettiğini doğrulayarak ölçün. Sepet, ödeme ve kişiselleştirilmiş sayfalar için yanlış cache kuralı kullanmayın. Bu noktada uygulama katmanındaki önbellek kuralları, içerik dağıtımı ve HTML cache gibi başlıklar da devreye girer. Eğer bu tarafla daha detaylı ilgilenmek istersen, WordPress ve WooCommerce’de CDN önbellek kuralları yazısı hızın dış çeperini toparlamana yardım eder.
Kapanış: Tuning Bir Maraton, Sprint Değil
Buffer pool, indeksler ve slow query analizi birbirini tamamlar. Bellek ayarı kötü sorguyu, indeks de uzun süren harici ödeme çağrısını tek başına çözmez. Doğru depolama tablosunu ve sürümü tanımlayıp ölçülen darboğaza müdahale etmek, sonraki kapasite kararlarını daha sağlam verilere dayandırır.
Son kontrolü sipariş bütünlüğüyle yapın: stok, ödeme durumu, kupon ve sipariş kaydı beklenen sonuçları vermelidir. Uzun işlemleri ve kilit sırasını inceleyin; deadlock olduğunda geri alınan transaction’ın tamamını sınırlı bir yeniden deneme politikasıyla ele alın; kilit bekleme zaman aşımını artırmak deadlock çözümü değildir. Harici ödeme gibi yan etkileri idempotent tasarlayın; yalnızca son SQL cümlesini tekrar çalıştırmak yeterli olmayabilir. Raporları read replica’ya taşımak ise açık sorgu yönlendirmesi ve gecikme toleransı gerektirir; ödeme sırasında güncel sipariş okumalarını körlemesine replica’ya göndermeyin. Değişiklik ve geri dönüş kayıtlarını ekibin görebileceği şekilde saklayın.
Kaynakça ve Faydalı Okumalar
Teknik ayrıntıları sade tutmaya çalıştım, ama derinleşmek istersen buralar güzel başlangıç noktaları: InnoDB Buffer Pool’un resmi anlatımı, EXPLAIN çıktısına pratik bir bakış ve pt-query-digest ile slow log özetleme. İçerideki büyük resmi görmek için ise şu üç rehber iyi arkadaşlık eder: WordPress için sunucu tarafı optimizasyon, WooCommerce kapasite planlama rehberi ve MySQL/MariaDB yedekleme stratejileri. Ayrıca WooCommerce HPOS veri modeli, MySQL 8.4 InnoDB değişkenleri ve geçici tablo sınırları için kurulu sürüme uygun belgeleri kullanın.
