Requêtes SQL lentes de type « SELECT SQL_CALC_FOUND_ROWS »

En cherchant la cause d'une lenteur dans WordPress, vous pouvez trouver des requêtes de cette forme :

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
LEFT JOIN wp_postmeta
ON ( wp_posts.ID = wp_postmeta.post_id )
...

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
INNER JOIN wp_postmeta
ON ( wp_posts.ID = wp_postmeta.post_id )
WHERE 1=1
...

Ces fragments sont des illustrations, pas des requêtes complètes à exécuter. SQL_CALC_FOUND_ROWS permet de calculer le total qui correspond aux filtres même si la requête ne renvoie qu'une page de résultats. Elle peut apparaître avec d'autres tables, pas seulement posts et postmeta.

Quand les tables grossissent, une requête qui examine trop de lignes peut prendre plus de temps et devenir un goulot d'étranglement. L'effet dépend des données et du plan d'exécution.

La présence de SQL_CALC_FOUND_ROWS n'identifie pas à elle seule la cause. Le coût peut dépendre des filtres, d'un JOIN sur les métadonnées, du volume de résultats, du tri appliqué ou des index déjà présents. Repérez d'abord l'extension, le thème ou la requête HTTP qui génère la requête SQL avec PHP X-Ray.

Avant de créer un index, gardez une sauvegarde restaurable et exécutez EXPLAIN sur la requête complète. Vérifiez aussi les index actuels de la table :

SHOW INDEX FROM wp_postmeta;

Un index combiné comme (post_id, meta_key) peut aider certains plans d'exécution, mais ce n'est pas une solution universelle et il ajoute un coût à chaque écriture. Si l'analyse confirme qu'il manque, utilisez un outil maintenu comme Index WP MySQL For Speed ou demandez au développeur de concevoir et de tester l'index sur un clone.

Après la modification, relancez EXPLAIN, comparez le temps sur plusieurs exécutions et vérifiez les insertions, les recherches, l'administration et les tâches planifiées. Supprimez l'index s'il n'améliore pas le plan ou s'il pénalise d'autres opérations.

Si le code n'a pas besoin de pagination

Dans une requête personnalisée construite avec WP_Query, le développeur peut envisager no_found_rows => true lorsque ni le total ni le nombre de pages ne sont utilisés. Ne l'appliquez pas globalement : cela casserait les fonctions qui dépendent de ces valeurs. La référence de WP_Query décrit ce paramètre.

Vérifiez aussi les filtres, le tri et le nombre de résultats demandés. Ne modifiez pas le cœur de WordPress et ne supprimez pas la clause d'une requête générée simplement parce qu'elle apparaît dans le rapport. La validation doit contrôler les résultats et la pagination, en plus du temps.