Dlaczego tabela `wp_options` nie ma indeksu na` autoload`?

Na początku każdej strony obsługiwanej przez WordPress znajduje się wywołanie MySQL w celu pobrania opcji:

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

Ponieważ w autoloadkolumnie nie ma indeksu , MySQL musi wyszukiwać WSZYSTKIE wiersze.

Natknąłem się również na komentarz tej odpowiedzi, mówiąc, że nie byłoby żadnego wzrostu wydajności, nawet gdyby istniał indeks.

W mojej aplikacji użyłem wielu wartości przejściowych, aby służyć jako zamiennik sesji. Działały świetnie, a ja mam własne procedury usuwania śmieci. Zauważyłem, że w wp_optionstabeli wszystkie moje wartości przejściowe (te zaczynające się od _transient_) mają autoload=no. Oczekuję, że liczba wierszy mojej wp_optionstabeli będzie rosła wraz ze wzrostem liczby użytkowników jednocześnie.

Chciałbym wiedzieć, dlaczego stół został zaprojektowany w ten sposób. I czy powinienem utworzyć indeks dla mojego konkretnego przypadku?

Nie ma indeksu, ponieważ potrzeba jego nigdy nie była wystarczająco silna.

W numerem # 14258 sugerowano, ale ponieważ większość opcji używać autoload=yesdomyślnie indeks będzie ignorowana tak.

Istnieje również wciąż otwarty bilet # 24044 _Dodaj indeks do wp_options w celu pomocy / poprawy wydajności_ .

Myślę, że powinieneś stworzyć indeks. Przetrwa ulepszenia. Może to nie pomóc w wydajności, ale możesz dodać prawdziwe dane statystyczne do tego biletu.

Aktualizacja z listopada 2019 r

Indeks został dodany do WordPress 5.3. Wreszcie. Zobacz wyżej wymieniony bilet nr 24044 oraz uwagi dewelopera do wydania .

Pamiętaj, że jeśli masz istniejący indeks o tej samej nazwie, otrzymasz ostrzeżenie podczas aktualizacji.

Z zestawu zmian :

Ta zmiana nie wpłynie na większość witryn, ale te z dużą liczbą wierszy wp_options, w których autoloadustawiono tylko niewielką liczbę , zauważą znaczną poprawę wydajności.
Witryny z dużą liczbą wierszy wp_options, z których wiele ma autoloadustawione, niestety zobaczą spadek wydajności w stosunku do już i tak bardzo wolnych zapytań, które wykonują, ale powinna to być niewielka liczba przypadków.

Prowadzę 3 blogi WP na dużej instancji Debian Squeeze i badałem, dlaczego mysql utknął na tym hoście przy zużyciu procesora 200% i obciążeniu systemu między 3 a 6. Patrząc na „pokaż listę procesów” w mysql, zrozumieliśmy, że W tym problemie uczestniczyła tabela wp_option, dlatego wykonaliśmy:

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

Po tej operacji obciążenie mysql pokazane na górze drastycznie spadło do 1%, a średnia wartość obciążenia instancji wynosi teraz 0,10.

Korzystamy z niektórych wtyczek, aby gdzieś w kodzie mogła być pętla, i może to być szczególna sytuacja, ale w naszym przypadku zmiana wydajności jest całkowicie zadziwiająca.

Nasza tabela wp_options ma 347 wierszy.

Podczas gdy @fuxia zaakceptowała poprawki dotyczące niektórych „zgłoszonych” powodów (z których większość została zgłoszona przez pracowników Automattic na różnych biletach Trac itp.), Podstawowym powodem, dla którego WordPress Core nie zawiera indeksu opcji automatycznego ładowania w wp_optionstabeli jest to, że Automattic martwił się, że negatywnie wpłynie to na wydajność baz danych MySQL, które nadal używały silnika MyISAM.

W szczególności wskazali na samą witrynę WordPress.org, która jest bardzo starą / złożoną bazą danych, jako przykładową stronę internetową, której wydajność byłaby ograniczona przez taki indeks.

Niemal wszystkie inne powody, dla których nie dodano indeksu za ostatnie 9 lat (tak, od 2010 r. W przypadku biletu Trac # 14258 i od 2013 r. W przypadku biletu Trac # 24044 ) były wielokrotnie niepoprawne przez dziesiątki członków Społeczność WordPress, ale zaangażowani pracownicy Automattic wielokrotnie ignorowali kilka niezależnych testów porównawczych i wrócili do wzmianki o obawach związanych z MyISAM.

Na szczęście pod koniec 2019 r. Z PHP 7.2 jest teraz „domyślna” wersja zalecana przez WordPress Core, a z silnikiem InnoDB teraz domyślnie w wersjach MySQL po wersji 5.5 oraz przy ciągłej presji ze strony różnych programistów, w tym @DanBUK, którzy utrzymywali ten problem przez lata , Automattic w końcu poddał się i postanowił dodać indeks automatycznego ładowania z WordPress 5.3+ w listopadzie 2019 r.

My w LittleBizzy uruchomiliśmy pierwszą znaną wtyczkę, która automatycznie dodała indeks, jeśli nie istniał, który jest nadal dostępny na GitHub i jest regularnie pobierany. Pamiętaj, że nie musisz już instalować takich wtyczek do stosu WordPress, jeśli korzystasz z WP Core 5.3 + ...