Comment se fait-il que la table `wp_options` n'ait pas d'index sur` autoload`?

Au début de chaque page servie par WordPress, il y a un appel MySQL pour récupérer les options:

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

Parce qu'il n'y a pas d'index sur la autoloadcolonne, MySQL doit rechercher TOUTES les lignes.

Je suis également tombé sur le commentaire de cette réponse disant qu'il n'y aurait pas de gain de performance même s'il y avait un indice.

Dans mon application, j'ai utilisé beaucoup de valeurs transitoires pour servir de remplacement de session. Ils ont très bien fonctionné et j'ai mes propres routines de collecte des ordures. J'ai remarqué que dans le wp_optionstableau, mes valeurs transitoires (celles commençant par _transient_) ont toutes autoload=no. Je m'attends à ce que le nombre de lignes de ma wp_optionstable augmente à mesure que le nombre d'utilisateurs simultanés augmente.

Je voudrais savoir pourquoi la table est conçue de cette façon. Et dois-je créer un index pour mon cas particulier?

Il n'y a pas d'index car le besoin n'en a jamais été assez fort.

Dans le ticket # 14258, il a été suggéré, mais comme la plupart des options sont utilisées autoload=yespar défaut, l'index serait de toute façon ignoré.

Il existe également le ticket # 24044 toujours ouvert _Ajouter un index à wp_options pour aider / améliorer les performances_ .

Je pense que vous devriez créer un index. Il survivra aux améliorations. Cela peut ne pas améliorer vos performances, mais vous pouvez ajouter de vraies données statistiques à ce ticket.

Mise à jour de novembre 2019

L'index a été ajouté à WordPress 5.3. Finalement. Voir le ticket # 24044 mentionné ci-dessus et les notes du développeur pour la version .

Notez que si vous avez un index existant du même nom, vous obtiendrez un avertissement pendant la mise à niveau.

Depuis le changeset :

La plupart des sites ne seront pas affectés par ce changement, mais ceux avec un grand nombre de lignes wp_options, dont seulement un petit nombre ont été autoloaddéfinis, verront une amélioration significative des performances.
Les sites contenant un grand nombre de lignes wp_options, dont beaucoup ont été autoloaddéfinis, verront malheureusement une baisse des performances en plus des requêtes déjà très lentes qu'ils exécutent, mais cela devrait être la minorité des cas.

J'exécute 3 blogs WP sur une grande instance de Debian Squeeze et j'explorais pourquoi mysql était bloqué sur cet hôte à 200% d'utilisation du processeur et à la charge du système entre 3 et 6. En regardant une 'liste de processus' dans mysql, nous avons compris le La table wp_option était impliquée dans ce problème, nous avons donc exécuté:

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

Après cette opération, la charge mysql, comme indiqué en haut, est tombée à 1% et la charge moyenne de l'instance est désormais de 0,10.

Nous utilisons certains plugins donc il pourrait y avoir une boucle quelque part dans le code, et cela pourrait être une situation particulière, mais dans notre cas, le changement de performances est tout à fait étonnant.

Notre table wp_options contient 347 lignes.

Alors que @fuxia a accepté la réponse, elle touche à certaines raisons "revendiquées" (dont la plupart ont été revendiquées par des employés d'Automattic sur divers tickets Trac, etc.), la raison sous - jacente pour que WordPress Core n'inclue pas d'index pour les options de chargement automatique dans le wp_optionstableau est que Automattic craignait que cela n'ait un impact négatif sur les performances des bases de données MySQL qui utilisaient toujours le moteur MyISAM.

Plus précisément, ils ont souligné le site Web WordPress.org lui-même, étant une base de données très ancienne / complexe, comme un exemple de site Web dont les performances seraient affectées par un tel index.

Presque toutes les autres raisons de ne pas ajouter l'indice depuis 9 ans (oui, depuis 2010 pour le ticket Trac # 14258 et depuis 2013 pour le ticket Trac # 24044 ) ont été à plusieurs reprises prouvées incorrectes par des dizaines de membres du Communauté WordPress, mais les employés d'Automattic impliqués ont ignoré à plusieurs reprises plusieurs tests de référence indépendants et sont revenus à mentionner les préoccupations de MyISAM.

Heureusement, fin 2019 avec PHP 7.2 maintenant la version "par défaut" recommandée par WordPress Core, et avec le moteur InnoDB désormais par défaut dans les versions de MySQL après 5.5 , et avec la pression continue de divers développeurs dont @DanBUK qui est resté sur la question pendant des années , Automattic a finalement cédé et a décidé d'ajouter l'index de chargement automatique à partir de WordPress 5.3+ en novembre 2019.

Chez LittleBizzy, nous avions lancé le premier plugin connu qui ajoutait automatiquement l'index s'il n'existait pas, qui est toujours disponible sur GitHub et téléchargé régulièrement. Veuillez noter que vous n'avez plus besoin d'installer de tels plugins sur votre pile WordPress si vous exécutez WP Core 5.3 + ...