J'ai utilisé un wp_query très simple pour recevoir 10 messages sur le site avec plus de 100 000 messages.
Cette requête exécutée sur le site wp-multi, la même requête vis-à-vis d'un petit site appartenant au même réseau (même serveur de base de données) prenait très peu de milisec (0.032888 | 0.021731 | 0.020796 | 0.02127)
La question principale est quand essayez de l'exécuter sur un site énorme (+ 100k posts).
Le dump wp_query est:
print_r($args);
// output
Array
(
[post_type] => post
[posts_per_page] => 10
[paged] =>
[orderby] => date
[order] => DESC
[meta_query] => Array
(
[0] => Array
(
[key] => city
[value] => Las Vegas
[compare] => =
)
)
[cat] => 2
)
vidage de $ wp_query-> request:
SELECT SQL_CALC_FOUND_ROWS wpui_2_posts.id
FROM wpui_2_posts
LEFT JOIN wpui_2_term_relationships
ON ( wpui_2_posts.id = wpui_2_term_relationships.object_id )
INNER JOIN wpui_2_postmeta
ON ( wpui_2_posts.id = wpui_2_postmeta.post_id )
WHERE 1 = 1
AND ( wpui_2_term_relationships.term_taxonomy_id IN ( 2 ) )
AND (( wpui_2_postmeta.meta_key = 'city'
AND wpui_2_postmeta.meta_value = 'las vegas' ))
AND wpui_2_posts.post_type = 'post'
AND ( wpui_2_posts.post_status = 'publish'
OR wpui_2_posts.post_status = 'private' )
GROUP BY wpui_2_posts.id
ORDER BY wpui_2_posts.post_date DESC
LIMIT 0, 10
Expliquez la requête de MySQL:
ID select_type table type possible_key key key_len ref rows Extra
1 SIMPLE wpui_2_term_relationships ref PRIMARY,term_taxonomy_id term_taxonomy_id 8 const 59097 Using index; Using temporary; Using filesort
1 SIMPLE wpui_2_posts eq_ref PRIMARY,type_status_date PRIMARY 8 wpdb.wpui_2_term_relationships.object_id 1 Using where
1 SIMPLE wpui_2_postmeta ref post_id,meta_key post_id 8 wpdb.wpui_2_term_relationships.object_id 3 Using where
cette requête a pris un temps considérable (5.715333 | 6.295236 | 5.110536 | 5.138607 | 5.164155)
Nombre actuel de lignes
Toute suggestion est vraiment appréciée
Voici le coupable:
[meta_query] => Array
(
[0] => Array
(
[key] => city
[value] => Las Vegas
[compare] => =
)
)
Les méta-requêtes sont lentes et la seule façon de les accélérer est de ne pas utiliser de méta-requêtes.
La table de méta de publication est optimisée pour extraire des paires clé/valeur où l'identifiant de publication est déjà connu. C'est pourquoi get_post_meta
est rapide.
Mais pour rechercher et filtrer des publications, ou pour rechercher/rechercher des publications par leur méta, les performances sont extrêmement médiocres. Ceci est voulu, de sorte que récupérer le méta de post est rapide.
Alors, comment filtrer/rechercher/trouver des publications en fonction de leurs données?
Les tables de taxonomie sont conçues pour rechercher des publications lorsque vous connaissez l'identifiant/le nom d'un terme. C’est ainsi que sont construits les tags et les catégories, et pourquoi ils sont tellement plus rapides que les méta-requêtes.
Le problème fondamental est que votre city
post meta aurait dû être une taxonomie personnalisée. Le passage à une taxonomie personnalisée améliorera la vitesse de votre requête de plusieurs ordres de grandeur.
Rappelles toi:
Et n’ayez pas peur d’utiliser les deux approches ou des approximations si vous avez une valeur plus compliquée, comme un prix.