Wieso hat `wp_options` table keinen Index für` autoload`?

Zu Beginn jeder von WordPress gelieferten Seite gibt es einen MySQL-Aufruf, um Optionen abzurufen:

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

Da es keinen Index für die autoloadSpalte gibt, muss MySQL ALLE Zeilen nachschlagen.

Ich bin auch auf den Kommentar dieser Antwort gestoßen, der besagt, dass es keinen Leistungsgewinn geben würde, selbst wenn es einen Index gäbe.

In meiner Anwendung habe ich viele vorübergehende Werte als Sitzungsersatz verwendet. Sie haben großartig funktioniert und ich habe meine eigenen Routinen zur Müllabfuhr. Mir ist aufgefallen, dass in der wp_optionsTabelle alle meine Übergangswerte (die mit beginnen _transient_) vorhanden sind autoload=no. Ich erwarte, dass die Anzahl der Zeilen meiner wp_optionsTabelle mit der Anzahl der gleichzeitigen Benutzer zunimmt.

Ich würde gerne wissen, warum der Tisch so gestaltet ist. Und sollte ich einen Index für meinen speziellen Fall erstellen?

Es gibt keinen Index, weil der Bedarf nie stark genug war.

In Ticket Nr. 14258 wurde dies vorgeschlagen, aber da die meisten Optionen autoload=yesstandardmäßig verwendet werden, wird der Index trotzdem ignoriert.

Es gibt auch das noch offene Ticket # 24044 _Add index to wp_options zur Unterstützung / Verbesserung der Leistung_ .

Ich denke, Sie sollten einen Index erstellen. Es wird Upgrades überleben. Dies kann möglicherweise nicht zu Ihrer Leistung beitragen, aber Sie können dem Ticket echte statistische Daten hinzufügen.

Update November 2019

Der Index wurde zu WordPress 5.3 hinzugefügt. Schließlich. Siehe das oben erwähnte Ticket Nr. 24044 und die Entwicklerhinweise zur Veröffentlichung .

Beachten Sie, dass Sie während des Upgrades eine Warnung erhalten, wenn ein Index mit demselben Namen vorhanden ist.

Aus dem Änderungssatz :

Die meisten Sites sind von dieser Änderung nicht betroffen, aber diejenigen mit einer großen Anzahl von Zeilen in wp_options, von denen nur eine kleine Anzahl autoloadfestgelegt wurde, werden eine signifikante Leistungsverbesserung feststellen.
Bei Websites mit einer großen Anzahl von Zeilen wp_options, von denen viele autoloadfestgelegt wurden, wird leider zusätzlich zu den bereits sehr langsamen Abfragen, die sie ausführen, eine Leistungsbeeinträchtigung angezeigt. Dies dürfte jedoch die Minderheit der Fälle sein.

Ich führe 3 WP-Blogs auf einer großen Debian Squeeze-Instanz aus und untersuche, warum MySQL bei 200% CPU-Auslastung und Systemlast zwischen 3 und 6 auf diesem Host hängen bleibt wp_option table war an diesem Problem beteiligt, daher haben wir Folgendes ausgeführt:

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

Nach dieser Operation ist die MySQL-Last, wie oben gezeigt, drastisch auf 1% gesunken, und der Durchschnitt der Instanzlast beträgt nun 0,10.

Wir verwenden einige Plugins, so dass es irgendwo im Code eine Schleife geben kann, und dies mag eine besondere Situation sein, aber in unserem Fall ist die Änderung der Leistung äußerst erstaunlich.

Unsere wp_options-Tabelle enthält 347 Zeilen.

Während @fuxia Antworten auf einige "beanspruchte" Gründe akzeptierte (von denen die meisten von Mitarbeitern von Automattic für verschiedene Trac-Tickets usw. behauptet wurden), ist der zugrunde liegende Grund dafür, dass WordPress Core keinen Index für die Autoload-Optionen in der wp_optionsTabelle enthält, der folgende Automattic befürchtete, dies würde sich negativ auf die Leistung von MySQL-Datenbanken auswirken, die noch die MyISAM-Engine verwendeten.

Insbesondere verwiesen sie auf die WordPress.org-Website selbst, eine sehr alte / komplexe Datenbank, als Beispiel für eine Website, deren Leistung durch einen solchen Index beeinträchtigt würde.

Fast alle anderen Gründe für die Nichtaufnahme des Index in den letzten 9 Jahren (ja, seit 2010 im Fall des Trac-Tickets Nr. 14258 und seit 2013 im Fall des Trac-Tickets Nr. 24044 ) wurden von Dutzenden von Mitgliedern der wiederholt als falsch erwiesen WordPress-Community, doch die beteiligten Automattic-Mitarbeiter ignorierten wiederholt mehrere unabhängige Benchmark-Tests und kehrten zurück, um MyISAM-Bedenken zu erwähnen.

Zum Glück war PHP 7.2 Ende 2019 die "Standard" -Version, die von WordPress Core empfohlen wurde, und die InnoDB-Engine in MySQL- Versionen nach 5.5. Verschiedene Entwickler, darunter @DanBUK, haben das Problem jahrelang unter Druck gesetzt , Gab Automattic schließlich nach und beschloss, den Autoload-Index ab WordPress 5.3+ im November 2019 hinzuzufügen.

Wir von LittleBizzy hatten das erste bekannte Plugin gestartet, das den Index automatisch hinzufügte, wenn er nicht vorhanden war. Dieser Index ist immer noch auf GitHub verfügbar und wird regelmäßig heruntergeladen. Bitte beachten Sie, dass Sie solche Plugins NICHT MEHR auf Ihrem WordPress-Stack installieren müssen, wenn Sie WP Core 5.3 + ausführen ...