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

14

Au début de chaque page servie par WordPress, il existe un appel MySQL pour rechercher des options:

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

Comme il n'y a pas d'index sur la colonne autoload , MySQL doit rechercher TOUTES les lignes.

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

Dans mon application, j'ai utilisé beaucoup de valeurs transitoires pour remplacer la session. Ils ont très bien travaillé et j'ai mes propres routines de collecte des ordures. J'ai remarqué que dans la table wp_options , mes valeurs transitoires (celles commençant par _transient_ ) ont toutes autoload=no . Je prévois que le nombre de lignes de ma table wp_options augmentera parallèlement au nombre d'utilisateurs simultanés.

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

    
posée He Shiming 04.05.2013 - 10:40

2 réponses

11

Il n'y a pas d'index car la nécessité de l'utiliser n'a jamais été assez strong.

Dans le ticket # 14258 , cela a été suggéré, mais comme la plupart des options utilisent autoload=yes par défaut, l'index serait ignoré de toute façon.

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

Je pense que vous devriez créer un index. Il survivra aux mises à niveau. Cela n’aidera peut-être pas votre performance, mais vous pourrez ajouter de vraies données statistiques à ce ticket.

    
réponse donnée fuxia 04.05.2013 - 11:56
4

J'exécutais 3 blogs WP sur une instance volumineuse de Debian Squeeze et cherchais à savoir pourquoi mysql était bloqué sur cet hôte à 200% d'utilisation du processeur et de charge du système entre 3 et 6. En regardant une 'liste de processus d'affichage' dans mysql, nous avons compris que 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, mysql load, comme indiqué en haut, est tombé à 1% et la charge moyenne de l’instance est désormais de 0,10.

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

Notre table wp_options comporte 347 lignes.

    
réponse donnée Fabio Pedrazzoli 16.12.2013 - 15:53

Lire d'autres questions sur les étiquettes