Diagnostiquer les requêtes LEFT JOIN lentes dans WordPress

Sur de grandes installations, une requête de WordPress qui filtre par catégories ou taxonomies peut prendre beaucoup de temps en combinant posts et term_relationships, en triant et en limitant les résultats. La présence de LEFT JOIN ne prouve pas à elle seule que la requête est mauvaise : les données, les filtres, les index et le plan d'exécution comptent.

Contexte du cas historique

Ce guide est né d'incidents avec des centaines de milliers d'articles et renvoie au ticket 54346 de WordPress, où sont étudiées les requêtes de catégories et des alternatives avec sous-requêtes.

Les résultats observés sur certaines installations ne garantissent pas des temps de quelques millisecondes pour n'importe quel volume de données. Ils ne font pas non plus d'un correctif du ticket une correction officielle applicable à toutes les versions.

Identifier la requête réelle

1. Reproduisez une URL lente et notez s'il y avait une session, du cache et des filtres.
2. Utilisez PHP X-Ray pour repérer la requête complète et le composant qui la génère.
3. Notez les versions de WordPress, de MySQL ou MariaDB et des extensions concernées.
4. Sur une copie avec des données représentatives, examinez le plan avec EXPLAIN et les index existants.

Comparez le nombre de lignes examinées, l'endroit où se fait le filtrage et la manière dont le tri est effectué. Un plan différent après une mise à jour mérite une analyse, mais il n'identifie pas automatiquement un seul coupable.

Évaluer une alternative

Le développeur peut tester une sous-requête, une expression équivalente, un index ou une autre façon d'utiliser WP_Query. Vérifiez qu'elle conserve les mêmes articles, le même tri, les mêmes exclusions, les doublons et la pagination, surtout avec des combinaisons de taxonomies.

Ne remplacez pas tous les JOIN et ne supprimez pas GROUP BY de façon globale. Une modification qui accélère une catégorie peut renvoyer des résultats incorrects dans une autre requête.

Appliquer et maintenir

Évitez de modifier directement les fichiers du cœur : les mises à jour écrasent les modifications et un ancien correctif peut ne plus s'appliquer. Si une adaptation temporaire est indispensable, le développeur doit la maintenir avec un contrôle de version, des tests et un moyen de la retirer.

Après la modification, comparez plusieurs exécutions et vérifiez les catégories, les recherches, la pagination et l'administration. Gardez le plan précédent et revenez en arrière si d'autres opérations se dégradent. Pour les requêtes qui calculent aussi des totaux, consultez le guide de SQL_CALC_FOUND_ROWS.