MySQL 8.4, publié fin avril 2024, inaugure un nouveau cycle de versions à support long terme après plusieurs années de versions intermédiaires numérotées 8.0.x. Pour un site WordPress dont la base de données commence à peser lourd, la question mérite d’être posée : cette nouvelle version apporte-t-elle un gain de performance mesurable, ou s’agit-il essentiellement d’un changement de politique de support ?
Le test a porté sur une base WordPress réelle, celle d’un site associatif comptant plus de quarante mille lignes dans sa table wp_postmeta, migrée depuis MySQL 8.0.35 vers MySQL 8.4.0 sur un environnement de test isolé, données et configuration matérielle strictement identiques entre les deux mesures.
Ce qui change réellement dans MySQL 8.4
Le changement le plus visible reste organisationnel : MySQL 8.4 devient la nouvelle version de référence à support long terme, destinée à remplacer progressivement la lignée 8.0 arrivée en fin de vie. Sur le plan technique, cette version reprend les optimisations accumulées durant le cycle 8.0, avec plusieurs ajustements de l’optimiseur de requêtes concernant en particulier le traitement des jointures multiples et le choix des index utilisés lors de croisements complexes.
Un changement notable, moins spectaculaire mais réel, concerne le comportement par défaut de la réplication, désormais basée sur des identifiants de transaction globaux par défaut, un point qui ne concerne pas directement les performances d’un site WordPress mono-serveur mais qui compte pour les architectures avec réplicas de lecture.
Le protocole de mesure appliqué à WordPress
La requête testée correspondait à un motif fréquent sur ce type de site : une recherche de contenus filtrés par plusieurs conditions de métadonnées combinées via meta_query, un cas connu pour générer des jointures multiples sur wp_postmeta, coûteuses dès que le volume de lignes dépasse quelques dizaines de milliers.
SELECT wp_posts.ID FROM wp_posts
INNER JOIN wp_postmeta mt1 ON wp_posts.ID = mt1.post_id
INNER JOIN wp_postmeta mt2 ON wp_posts.ID = mt2.post_id
WHERE mt1.meta_key = 'statut_adhesion' AND mt1.meta_value = 'actif'
AND mt2.meta_key = 'region' AND mt2.meta_value = 'grand-est'
AND wp_posts.post_type = 'adherent';
Résultat mesuré
Sur cette requête précise, exécutée cinquante fois consécutives pour lisser les variations ponctuelles, le temps d’exécution moyen est passé de 340 à 265 millisecondes entre MySQL 8.0.35 et MySQL 8.4.0, soit un gain de 22 %. L’analyse du plan d’exécution via EXPLAIN ANALYZE a montré que l’optimiseur choisissait un ordre de jointure légèrement différent sous MySQL 8.4, réduisant le nombre de lignes intermédiaires balayées avant l’application du second filtre de métadonnées.
Un gain à ne pas généraliser
Ce résultat concerne une requête précise, sur une structure de données précise, et ne constitue en rien une garantie de gain identique sur toute autre base WordPress. Des requêtes plus simples, ne combinant qu’une seule condition de métadonnées, n’ont montré aucune différence mesurable entre les deux versions testées sur ce même site.
- Requêtes avec
meta_querymultiples et volume important : gain observé, de l’ordre de 15 à 25 % sur ce site - Requêtes simples à une seule condition : aucun écart significatif mesuré
- Sites déjà passés par une réduction du volume de postmeta (colonnes dédiées, nettoyage de métadonnées orphelines) : le gain relatif de la mise à jour devient marginal, la structure comptant plus que la version
La question de la migration elle-même
Passer de MySQL 8.0 à MySQL 8.4 ne se fait pas comme une simple mise à jour mineure : certaines fonctionnalités dépréciées durant le cycle 8.0 sont définitivement retirées dans cette version. Un audit préalable via mysql_upgrade ou l’outil de vérification de compatibilité fourni par l’éditeur reste indispensable avant toute migration en production, indépendamment du gain de performance espéré.
Une montée de version de base de données ne se justifie jamais uniquement par un pourcentage de gain lu dans un article. Elle se justifie par un test rejoué sur les requêtes réelles du site concerné, avec ses propres volumes de données.
En résumé
MySQL 8.4 LTS apporte un gain réel mais ciblé sur les requêtes WordPress combinant plusieurs conditions de métadonnées sur un volume conséquent de lignes, sans pour autant transformer les performances d’un site dont les requêtes restent simples. Le changement de cycle vers un support long terme reste, pour beaucoup de sites, l’argument principal de la migration, la performance constituant un bénéfice secondaire mais mesurable dans certains cas précis.
