MySQL 8.0 est sorti en avril 2018 sans query cache. La fonctionnalité, présente depuis les tout débuts du moteur, a été retirée purement et simplement, et non pas seulement désactivée par défaut. Pour beaucoup de développeurs WordPress qui avaient appris à s’appuyer dessus sur des installations plus anciennes, la nouvelle est passée presque inaperçue, faute d’avoir compris ce que ce cache faisait réellement.
Le query cache stockait le résultat brut d’un SELECT en associant la chaîne exacte de la requête à sa réponse. Dès qu’une seule ligne d’une table impliquée changeait, toutes les entrées de cache liées à cette table étaient invalidées, sans distinction fine. Sur un site WordPress où wp_posts et wp_postmeta sont réécrits en permanence, ce mécanisme finissait par coûter plus cher qu’il ne rapportait.
Ce que faisait réellement le query cache
Le fonctionnement était simple sur le papier : une requête identique au caractère près retournait un résultat déjà calculé, sans repasser par l’optimiseur ni relire les tables. Le problème venait du verrou global nécessaire pour gérer ce cache partagé entre toutes les connexions. Sur un serveur avec plusieurs cœurs et beaucoup de connexions simultanées, ce verrou devenait un point de contention sérieux, documenté par l’équipe MySQL elle-même comme l’une des raisons principales de la suppression.
Concrètement, deux requêtes qui ne différaient que par un espace ou une casse de mot-clé ne bénéficiaient d’aucun partage de cache. Sur WordPress, où WP_Query génère des requêtes construites dynamiquement avec des identifiants de site, de taxonomie ou de méta-clé qui varient légèrement, le taux de réutilisation réel du cache était souvent plus faible qu’attendu.
Pourquoi WordPress n’a pas vraiment souffert
La majorité des installations sérieuses reposaient déjà, avant même la sortie de MySQL 8.0, sur un cache d’objets applicatif (Memcached ou un cache de fichiers via un plugin dédié). Ce cache d’objets fonctionne à un niveau différent : il stocke le résultat déjà transformé en objets PHP, indexé par une clé logique choisie par le développeur, avec une durée de vie et une invalidation maîtrisées via wp_cache_set() et wp_cache_delete(). Ce contrôle fin rendait le query cache MySQL largement redondant sur ces sites.
Ce qui reste pour accélérer les lectures répétées
Sans query cache, trois leviers restent disponibles pour réduire la charge de lecture répétée :
- Le buffer pool InnoDB, qui garde en mémoire les pages de données et d’index les plus consultées, indépendamment du texte de la requête.
- Le cache d’objets persistant de WordPress, déjà mentionné, qui évite de repasser par MySQL pour des lectures identiques côté application.
- Les transients, utiles pour des calculs coûteux et rarement invalidés, comme un comptage de produits par catégorie.
Le rôle sous-estimé du buffer pool
Augmenter innodb_buffer_pool_size pour qu’il couvre la totalité des tables actives d’un site est souvent plus rentable que n’importe quelle astuce de cache applicatif mal réglée. Sur un site avec quelques centaines de mégaoctets de données, un buffer pool dimensionné à un gigaoctet ou deux permet de garder l’essentiel des pages chaudes en mémoire, ce qui reproduit une partie du bénéfice que le query cache prétendait apporter, sans son coût de verrouillage.
Une confusion fréquente à éviter
Beaucoup de tutoriels WordPress plus anciens recommandaient encore d’activer query_cache_type dans my.cnf, un réglage qui n’a simplement plus aucun effet sur MySQL 8.0 et n’est même plus reconnu par le serveur. Garder cette ligne dans une configuration migrée depuis un ancien serveur ne casse rien, mais elle ne sert à rien non plus : autant la retirer pour éviter toute confusion lors d’un futur audit de configuration.
En résumé
La disparition du query cache dans MySQL 8.0 n’a pas créé de trou de performance pour WordPress, parce que le vrai travail de mise en cache se faisait déjà ailleurs : dans l’objet cache applicatif et dans le buffer pool InnoDB. La leçon à retenir dépasse ce cas précis : avant de s’appuyer sur un mécanisme de cache transversal et automatique, il vaut mieux vérifier qui, dans la pile, fait réellement le travail utile, pour ne pas être surpris le jour où ce mécanisme disparaît.
