Nasıl olur da 'wp_options` tablosunda' autoload`da bir indeks yoktur?


15

WordPress tarafından sunulan her sayfanın başında, seçenekleri getirmek için bir MySQL çağrısı vardır:

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

autoloadSütunda dizin olmadığından , MySQL TÜM satırları aramalıdır.

Ayrıca , bir endeks olsa bile performans kazancı olmayacağını söyleyerek bu cevabın yorumuyla karşılaştım .

Uygulamamda, oturum değiştirme işlevi görmek için çok fazla geçici değer kullandım. Harika çalıştılar ve kendi çöp toplama rutinlerim var. wp_optionsTabloda, geçici değerlerimin (ile başlayanların _transient_) hepsinin olduğunu fark ettim autoload=no. wp_optionsEşzamanlı kullanıcı sayısı arttıkça masamın satır sayısının artmasını bekliyorum.

Masanın neden bu şekilde tasarlandığını bilmek istiyorum. Özel durumum için bir dizin oluşturmalı mıyım?

Yanıtlar:


11

Endeks yoktur çünkü buna olan ihtiyaç asla yeterince güçlü olmamıştır.

In bilet # 14258 o önerildi, ancak çoğu seçenekleri kullandıkları için autoload=yesvarsayılan olarak, endeks yine göz ardı edilecektir.

Ayrıca hala açık bir bilet var # 24044 _ Performansa yardımcı olmak / performansı artırmak için wp_options dizinini ekleyin_ .

Bence bir dizin yaratmalısın. Yükseltmelerden kurtulur. Performansınıza yardımcı olmayabilir, ancak bu bilete gerçek istatistiksel veriler ekleyebilirsiniz.


Kasım 2019 Güncellemesi

Dizin WordPress 5.3'e eklendi. En sonunda. Yukarıda belirtilen 24044 numaralı bilete ve sürümün geliştirici notlarına bakın .

Aynı ada sahip bir dizininiz varsa, yükseltme sırasında bir uyarı alacağınızı unutmayın.

Gönderen Changeset :

Çoğu site bu değişiklikten etkilenmeyecektir, ancak çok az sayıda satır içeren wp_options, yalnızca az sayıda autoloadayarlanmış olanlar, önemli bir performans artışı görecektir.
Çok sayıda satır içeren siteler wp_options, birçoğu autoloadayarlanmış olsa da, maalesef çalıştırdıkları çok yavaş sorguların üstünde bir performans cezası görecek, ancak bu durumların azınlığı olmalıdır.


1
# 24044 ile okumadan anlayabildiğim kadarıyla, eski MyISAM tabloları performans gerilemesi, yeni InnoDB tabloları çoğunlukla fayda sağlayacaktır. Tüm eski tablolarımı InnoDB dönüştürüyorum ve autoloadsütun üzerinde bir dizin ayarlama .
lkraav

Yıllar sonra, sonunda WordPress ekibi tarafından ele alındı. Dizinine bir dizin eklendiwp_options.autoload . Kaynaklar: make.wordpress.org/core/2019/10/15/… ... ve ... core.trac.wordpress.org/ticket/24044#comment:87 ... Bu özelliği öneren @DanBUK şerefine 2013 yılında
Jee

Teşekkürler @Jee, cevabı güncelledim.
fuxia

5

Bir Debian Squeeze büyük örnek üzerinde 3 WP blog çalıştırıyorum ve mysql neden% 200 CPU kullanımı ve sistem yükü 3 ve 6 arasında sıkışmış olduğunu araştırıyordum. Mysql içinde bir 'gösteri listesi' bakarak wp_option tablosu bu sayıya dahil oldu, bu yüzden yürüttük:

alter table wp_options add index autoload_idx(`autoload`);

Bu işlemden sonra üstte gösterildiği gibi mysql yükü büyük oranda% 1'e düştü ve örnek yük ortalaması şimdi 0.10 oldu.

Bazı eklentileri kullanıyoruz, böylece kodun bir yerinde bir döngü olabilir ve bu belirli bir durum olabilir, ancak bizim durumumuzda performanstaki değişiklik tamamen şaşırtıcıdır.

Wp_options tablomuzda 347 satır var.


2
Paylaşım için teşekkürler. WordPress'in bu seçenek tablosunu ele alırken bir kusuru olduğunu düşündüm. O kadar küçük ki sorgulamamalı. Herkes için bir select *kez olmalı . Bunun yerine, her seçenek için sorgulama yapıyor, bu yüzden bir dizin koymak büyük bir fark yaratacak.
13'te

0

İken @fuxia kabul cevabı bazı "iddia" nedenlere dokunuşlar (çoğu çeşitli Trac biletleri, vb Automattic çalışanları tarafından iddia edildi), altta yatan nedeni içinde özdevinimli_yükle seçenekleri için bir dizini gibi WordPress Core wp_optionsmasanın olmasıdır Automattic, hala MyISAM motorunu kullanan MySQL veritabanlarının performansını olumsuz etkileyeceğinden endişeli.

Özellikle, çok eski / karmaşık bir veritabanı olan WordPress.org web sitesinin kendisine, performansı böyle bir endekse zarar verecek örnek bir web sitesi olarak işaret ettiler.

Neredeyse tüm 9 yıldır endeksi ekleyerek değil başka nedenler (Trac bilet durumunda 2010 yılından beri, evet # 14258 ve Trac bilet durumunda 2013 yılından bu yana # 24044 ) art arda üyelerinin onlarca tarafından yanlış kanıtlanmış edildi WordPress topluluğu, ancak katılan Otomotiv çalışanları birçok bağımsız karşılaştırma testini tekrar tekrar görmezden geldi ve MyISAM endişelerinden bahsetmeye geri döndü.

Neyse ki, 2019'un sonlarında PHP 7.2 ile şimdi WordPress Core tarafından önerilen "varsayılan" sürüm ve 5.5'ten sonra MySQL sürümlerinde varsayılan olarak InnoDB motoru ile ve yıllardır sorun devam eden @DanBUK dahil çeşitli geliştiricilerin sürekli baskısıyla , Automattic nihayet verdi ve Kasım 2019'da WordPress 5.3+ itibariyle otomatik yük endeksini eklemeye karar verdi.

LittleBizzy olarak, eğer mevcut değilse, indeksi otomatik olarak ekleyen, GitHub'da hala mevcut olan ve düzenli olarak indirilen bilinen ilk eklentiyi başlattık . WP Core 5.3 + çalıştırıyorsanız, WordPress yığınınıza bu tür eklentileri yüklemeniz gerekmediğini lütfen unutmayın ...

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.