Manque d'index composites pour les méta-tables
Pourquoi la table wp_commentmeta ne possède-t-elle pas d'index composite (comment_id, meta_key) par défaut? Je crois que c'est le seul index utile pour cette table, je me trompe?
Au lieu de cela, il a un étrange ensemble d'index:
mysql> show create table wp3_commentmeta;
...
PRIMARY KEY (`meta_id`),
KEY `comment_id` (`comment_id`),
KEY `meta_key` (`meta_key`)
...
La même chose à propos de wp_postmeta.
Un schéma WordPress "sync" standard via dbDelta() ne fera qu'ajouter des index, pas les supprimer. Même chose pour les champs. Nous ne touchons jamais non plus le schéma de stockage, il s'agirait donc du comportement par défaut de MySQL (qui, dans les dernières versions, s'appelle désormais InnoDB).
Sur le visage, un index comment_id_meta_key est parfaitement logique. Mais si vous regardez comment WordPress utilise réellement ses tables de métadonnées, le cas d'utilisation est moins évident.
Lorsque vous demandez une clé méta pour un objet (publication, commentaire ou utilisateur), nous extrayons toutes les clés méta de cet objet , puis nous les mettons en cache. Ceci est très important, car il ne nécessite qu'un index comment_id, pas un index comment_id_meta_key.
Bien sûr, cette requête utiliserait toujours un index comment_id_meta_key, mais cet index serait beaucoup plus grand, car plutôt que d'être une colonne d'entiers, vous examineriez également une colonne de varchar(255). C'est donc moins efficace pour le cas d'utilisation principal de métadonnées.
L'API pour l'exemple suivant est limitée: une requête pour extraire toutes les clés méta de tous les objets (probablement pour déterminer quels objets possèdent des clés méta). Ceci, encore une fois, est un bon cas d’utilisation pour un index meta_key, pas un index comment_id_meta_key.
L'autre grande API pour les métadonnées interroge les méta-requêtes. Ce ne sont pas (et ne prétendent pas être) efficaces. Ils interrogent meta_key (et parfois meta_value) dans l'espoir de renvoyer des ID d'objet pour la requête d'objet principale (commentaires internes ou à gauche, commentmeta, en général). Encore une fois, comment_id_meta_key n'aide pas ici.
La mise à l'échelle de WordPress est un mélange de mise en cache, d'optimisation de requête et, bien sûr, d'optimisation de base de données. Si vous constatez que vous exécutez des requêtes utilisant ces index, il n’ya vraiment rien de mal à les ajouter. Ce n'est pas très différent de passer à InnoDB (oui, vous devriez le faire). Je ne suis tout simplement pas familier avec une requête préparée par le noyau qui manquerait les index existants mais bénéficierait de comment_id_meta_key.
Vous n'êtes pas limité dans ce cas. Créez simplement les index composites nécessaires et supprimez tous les index en double. Par exemple:
ALTER TABLE wp3_commentmeta ADD INDEX comment_id_meta_key_ndx (comment_id, meta_key);
ALTER TABLE wp3_commentmeta DROP INDEX comment_id;
Assurez-vous simplement que vos requêtes utilisent réellement les index nouvellement créés.