Table des matières de l'article :
Dans le monde de la gestion de bases de données, MySQL Query Cache joue un rôle crucial depuis des années. Cette fonctionnalité était destinée à améliorer les performances de la base de données en stockant les résultats des requêtes pour les réutiliser ultérieurement. Cependant, avec l’arrivée de MySQL 8, le Query Cache a finalement été abandonné. Mais pourquoi une fonctionnalité apparemment utile a-t-elle été supprimée ? Dans cet article, nous explorerons en détail les raisons de cette décision.
Qu'est-ce que le cache de requêtes MySQL ?
Le cache de requêtes MySQL, Introduit pour la première fois avec MySQL version 4.0 en 2002, il était destiné à constituer une partie de mémoire dédiée au sein du démon MySQL pour stocker les résultats des requêtes. Son fonctionnement reposait sur un principe relativement simple mais efficace : si la même requête avait été exécutée de manière répétée, le Query Cache aurait permis d'éviter de retraiter cette requête en fournissant directement le résultat précédemment stocké. Cette fonctionnalité était particulièrement utile à l'époque où les ressources matérielles, telles que les processeurs et les disques, étaient considérées comme des actifs de grande valeur et n'étaient pas aussi facilement accessibles qu'aujourd'hui. À cette époque, optimiser l’utilisation des ressources disponibles était fondamental et le Query Cache représentait une solution efficace pour réduire la charge de travail des systèmes.
Au fil des années, avec l'évolution architecturale des processeurs, des langages de programmation, des serveurs, l'avènement du Cloud et de nouvelles technologies et paradigmes, la signification du cache de requêtes MySQL original a de plus en plus perdu son intention initiale, devenant très souvent une arnaque et une arnaque. pas un pro, tant dans la phase de conception du SGBD que dans les entreprises qui ont développé MySQL au fil du temps, de MySQL AB à Sun Microsystem en passant par l'actuel Oracle, au point de générer charge et rapidité envers les développeurs et ingénieurs système qui ont fait confiance à ce fonctionnalité désormais obsolète et ancienne.
À partir de MySQL 5.7 lancé en 2015, le cache de requêtes a été déclaré officiellement obsolète et a été officiellement supprimé en tant que fonctionnalité à partir de MySQL 8 lancé en avril 2018.
On peut donc dire que depuis au moins 10 ans l'utilisation du Query Cache intégré à MySQL commence à être critiquée et jugée peu utile, et que depuis au moins 2018, Oracle a décidé de supprimer cette fonctionnalité.
Raisons de désactiver le cache de requêtes MySQL
1. Correspondance exacte des requêtes
Le cache de requêtes MySQL stocke les résultats des requêtes en utilisant une version hachée des requêtes. Cette approche signifie que même de petites différences entre deux requêtes entraînent un hachage différent, compromettant l'efficacité de la mise en cache pour des requêtes légèrement différentes. Par exemple, une requête comme SELECT id, field1, field2 FROM table; est considéré comme différent de SELECT * FROM table; même si les champs sélectionnés sont les mêmes et dans le bon ordre.
L'ajout de commentaires dans les requêtes génère également une version hachée différente. Avec l'utilisation d'ORM et d'APM dynamiques modernes, les commentaires dans les requêtes sont souvent utilisés pour retracer le processus et inclure des indications telles que des horodatages et des noms d'hôte. L'ajout d'un horodatage et d'un nom d'hôte pour le suivi des processus offre un avantage spécifique, mais rend la requête unique, rendant ainsi le cache de requêtes inutile.
Il est intéressant de noter que les versions MariaDB 5.5, MariaDB 10.x et MySQL 5.x de Percona incluent une fonctionnalité qui supprime les commentaires des requêtes lorsqu'elles sont stockées dans le cache de requêtes. Cette fonctionnalité peut être activée via la variable système nommée query_cache_strip_comments.
2. Caractéristiques non déterministes
L'une des limitations les plus importantes du cache de requêtes MySQL réside dans son incapacité à gérer des éléments non déterministes. Le concept de « non déterministe » fait référence aux éléments d'une requête qui peuvent produire des résultats différents à chaque fois qu'ils sont exécutés. Les exemples courants incluent l'utilisation de tables temporaires, de variables utilisateur et de fonctions telles que RAND() o NOW().
Dans le cas de fonctions non déterministes comme RAND(), qui génère un nombre aléatoire, ou NOW(), qui renvoie l'instant courant, le Query Cache s'avère inefficace. La raison est simple : le résultat d’une requête contenant de telles fonctions change à chaque exécution, rendant inutile la mémorisation du résultat précédent. Cet aspect est particulièrement pertinent dans de nombreuses applications modernes, où l’utilisation de fonctions basées sur le temps ou sur des données générées aléatoirement est fréquente.
Par exemple, imaginez une requête qui utilise NOW() pour sélectionner les enregistrements jusqu'à l'heure actuelle. Si cette requête est exécutée à des moments différents, les résultats varieront en fonction de l'heure actuelle, rendant inutile un résultat précédemment stocké dans le cache de requêtes. De plus, de nombreuses applications et frameworks modernes s'appuient fortement sur ces fonctions pour déterminer la visibilité des données ou pour générer du contenu dynamique, ce qui rend le cache de requêtes peu pratique et souvent inutilisé.
L'incapacité du Query Cache à gérer correctement ces éléments non déterministes limite considérablement son utilisation dans les architectures de bases de données modernes, où la flexibilité et la capacité à gérer des données dynamiques et en constante évolution sont essentielles.
3. Invalidation du cache pour l'insertion, la mise à jour, la suppression
L'un des problèmes les plus importants du cache de requêtes MySQL est lié à sa gestion des opérations INSERT, UPDATE et DELETE. Chaque fois que l'un de ces événements se produit, le cache de requêtes invalide automatiquement les résultats stockés liés aux tables impliquées.. Ce mécanisme est conçu pour empêcher la fourniture de données obsolètes, garantissant que la base de données renvoie toujours les données les plus à jour.
Cependant, cette stratégie entraîne un certain nombre d’inefficacités. Dans un environnement de base de données dynamique, où les opérations d'insertion, de mise à jour et de suppression sont fréquentes, le cache de requêtes peut se retrouver à invalider et à recréer le cache à une fréquence élevée. Ce processus consomme non seulement de précieuses ressources système, mais réduit également considérablement les avantages que la mise en cache devrait apporter.
Par exemple, considérons une table fréquemment utilisée pour les transactions ou les mises à jour de données. Toute modification de cette table – même la plus minime – entraînera l'invalidation de tous les résultats de requêtes précédemment mis en cache incluant cette table.. Dans les scénarios où les tables sont soumises à des mises à jour fréquentes, ce comportement rend le cache de requêtes presque inutile, puisque les données mises en cache sont continuellement invalidées et rarement utilisées.
De plus, ce mécanisme d'invalidation n'est pas sélectif ; il ne fait pas de distinction entre les petits changements insignifiants et les mises à jour importantes des données. Par conséquent, même une seule insertion ou une petite modification peut entraîner l'invalidation d'une grande partie du cache, augmentant ainsi la charge de travail sur le serveur et diminuant les performances globales.
En résumé, l’approche adoptée par MySQL Query Cache pour gérer les mises à jour des données s’avère être une arme à double tranchant : Tout en garantissant la fraîcheur des données, cela compromet simultanément l'efficience et l'efficacité de la mise en cache, en particulier dans les environnements où les opérations de base de données sont à haute fréquence.
4. Mise en cache basée sur des tables
MySQL Query Cache est basé sur un principe de mise en cache orienté table. Cela signifie que chaque fois qu'une table subit une modification, toutes les entrées de cache associées à cette table sont invalidées. Bien que cette stratégie puisse sembler raisonnable pour maintenir l’intégrité des données, elle présente des inconvénients importants en termes d’efficacité de la mise en cache, en particulier dans les environnements dotés de bases de données dynamiques et fréquemment mises à jour.
Dans un contexte réel, les tables de bases de données sont souvent soumises à des changements continus, petits et grands. Celles-ci peuvent inclure des mises à jour de routine, de nouvelles entrées de données ou des suppressions. Avec la mise en cache basée sur des tables, même le plus petit changement, tel que la mise à jour d'un seul champ, peut déclencher l'invalidation d'une grande quantité de données mises en cache liées à cette table.
Ce mécanisme devient problématique, en particulier pour les requêtes complexes impliquant plusieurs tables. Par exemple, une requête de jointure qui joint plusieurs tables sera affectée par l'invalidation du cache si même l'une des tables impliquées subit une modification. En conséquence, les requêtes les plus coûteuses qui nécessiteraient le plus les avantages de la mise en cache sont souvent celles les plus pénalisées par cette approche.
De plus, dans les scénarios où certaines tables sont soumises à des modifications fréquentes, le cache de requêtes perd une grande partie de son utilité. L'invalidation et la régénération continues du cache consomment non seulement des ressources du serveur, mais ralentissent également le temps de réponse global de la base de données, puisque les requêtes doivent être réexécutées plutôt que de récupérer les résultats du cache.
Enfin, cette approche manque de granularité. Il ne fait pas de distinction entre les tableaux qui changent rarement et ceux qui changent constamment. Par conséquent, la mise en cache basée sur les tables n'est pas optimisée pour une utilisation dans des environnements complexes et dynamiques, ce qui a un impact négatif sur les performances globales de la base de données.
5. Aucune possibilité de spécifier les requêtes à mettre en cache.
L'une des faiblesses les plus évidentes du cache de requêtes MySQL est sa nature rigide, décrite comme une approche « tout ou rien ». Cela signifie que les administrateurs et les développeurs de bases de données n'ont pas la possibilité de personnaliser ou d'influencer les requêtes mises en cache et pendant combien de temps. Cette rigidité peut entraîner des inefficacités et des complications importantes dans la gestion du cache, en particulier dans les bases de données complexes et différenciées.
Dans un environnement de base de données idéal, il serait utile de pouvoir spécifier quelles tables ou schémas doivent être mis en cache, ou même quels types spécifiques de requêtes bénéficieraient le plus de la mise en cache. Cependant, avec MySQL Query Cache, cette granularité de contrôle n'est pas possible. Le système est conçu pour mettre en cache les requêtes sans discernement, sans faire de distinction entre les requêtes qui bénéficient de la mise en cache et celles pour lesquelles la mise en cache pourrait même s'avérer contre-productive.
Par exemple, dans une base de données contenant à la fois des tables rarement modifiées et des tables fréquemment mises à jour, il serait logique de vouloir mettre en cache uniquement les requêtes liées aux premières. Cependant, le cache de requêtes de MySQL n'offre pas cette flexibilité. En conséquence, des ressources précieuses sont gaspillées lors de la mise en cache des requêtes des tables dynamiques, dont les entrées du cache seront presque immédiatement invalidées, tandis que les tables statiques, qui pourraient bénéficier davantage de la mise en cache, ne bénéficient pas d'un traitement préférentiel.
De plus, le manque de contrôle sur la durée de vie du cache signifie que les données peuvent rester dans le cache pendant des périodes moins qu'optimales. Dans certains cas, cela pourrait conduire à des données obsolètes, tandis que dans d'autres, les requêtes pourraient être rechargées trop fréquemment, gaspillant ainsi les ressources informatiques.
La rigidité du Query Cache s'avère donc être un obstacle dans des situations où une gestion plus fine et ciblée du cache pourrait améliorer significativement les performances globales de la base de données. Cette limitation représente un inconvénient évident à une époque où la personnalisation et l’optimisation des ressources sont essentielles à l’efficacité opérationnelle.
6. Verrouillage des opérations sur le cache de requêtes
Un aspect essentiel du cache de requêtes de MySQL est son mécanisme de verrouillage. Chaque fois qu'une requête est mise en cache ou que le cache doit être invalidé (par exemple, suite à une opération d'insertion, de mise à jour ou de suppression), le système impose un verrouillage exclusif sur l'ensemble du cache. Cela signifie que pendant le traitement de ces opérations, aucun autre processus ne peut accéder au cache de requêtes.
Dans les environnements comportant un volume élevé d’opérations simultanées, cela peut devenir un sérieux goulot d’étranglement. Lorsque plusieurs threads tentent d'accéder au cache en même temps, des ralentissements importants peuvent survenir car chaque thread doit attendre son tour pour accéder au cache. Ce problème est exacerbé dans les systèmes dotés d'un volume de cache important, où les opérations d'invalidation et de mise à jour peuvent prendre plus de temps.
7. Conception orientée processeur unique
Le cache de requêtes MySQL est le produit d'une époque où l'architecture informatique était dominée par des serveurs monoprocesseurs. Ce contexte historique est crucial pour comprendre ses limites actuelles. Au moment de sa conception, les préoccupations concernant le multithreading et la gestion de la concurrence entre plusieurs cœurs étaient pratiquement inexistantes. Les serveurs à processeur unique géraient les opérations de manière séquentielle et le cache de requêtes était optimisé pour ce type de traitement linéaire.
Cependant, avec l'évolution de la technologie et l'introduction des processeurs multicœurs, la dynamique de l'informatique serveur a radicalement changé. Les processeurs multicœurs modernes peuvent exécuter plusieurs threads en parallèle, ce qui augmente considérablement l'efficacité et la capacité à gérer des charges de travail élevées. Cette évolution a conduit à un changement fondamental dans les attentes en matière de performances pour les systèmes de bases de données.
Malgré ces évolutions, Le cache de requêtes de MySQL n'a pas été suffisamment adapté pour tirer parti des capacités des processeurs multicœurs. Son architecture originale, basée sur un modèle de traitement séquentiel, n'est pas optimisée pour gérer des opérations concurrentes. Cela devient particulièrement problématique dans les environnements à forte concurrence, où plusieurs threads tentent d'accéder ou de modifier le cache simultanément. Au lieu de bénéficier du parallélisme offert par les processeurs multicœurs, le Query Cache devient un goulot d'étranglement, puisque ses mécanismes de verrouillage et de synchronisation ne sont pas adéquats pour gérer efficacement la concurrence.
La conséquence directe de cette limitation est une sous-utilisation des ressources informatiques disponibles dans les serveurs modernes. Plutôt que de répartir efficacement la charge de travail entre les cœurs, Query Cache a tendance à limiter les opérations à un seul thread, ce qui ralentit le traitement global et diminue la réactivité du système de base de données. Cela a non seulement un impact négatif sur les performances globales, mais limite également l'évolutivité des systèmes de bases de données, un facteur critique à une époque où la vitesse de traitement et la capacité à gérer de gros volumes de données sont primordiales.
8. Conception orientée serveur unique
MySQL Query Cache, dans sa conception originale, a été optimisé pour les environnements où la base de données résidait sur un seul serveur. Dans ce scénario, toutes les lectures, écritures et mises en cache étaient effectuées sur site, ce qui était idéal pour l'époque. Dans un tel environnement, la centralisation des données et des opérations de cache garantissait une réponse rapide aux requêtes et une gestion efficace des données. La mise en cache locale s'est avérée particulièrement efficace car toutes les données étaient immédiatement accessibles et gérables au sein d'un seul système.
Cependant, à mesure que les infrastructures informatiques évoluent et évoluent vers des architectures distribuées et des solutions cloud, le modèle traditionnel de serveur unique a été dépassé.. Les architectures informatiques modernes ont tendance à répartir la charge de travail sur plusieurs serveurs, souvent géographiquement dispersés. Ces environnements exploitent la réplication des données, l'équilibrage de charge et d'autres stratégies pour optimiser la disponibilité, la résilience et l'évolutivité du système.
Dans ces architectures distribuées, le modèle de mise en cache centralisé de MySQL Query Cache commence à montrer ses limites. La gestion du cache dans un environnement distribué nécessite une synchronisation minutieuse entre plusieurs serveurs pour garantir que les données sont cohérentes et à jour sur tous les nœuds. Ce processus de synchronisation peut être complexe et nécessiter une quantité importante de ressources réseau et informatiques, contrecarrant les avantages de la mise en cache elle-même.
De plus, la nature centralisée du Query Cache n’exploite pas pleinement les avantages des architectures distribuées, tels que la redondance et la résilience. Dans un système distribué, la capacité de continuer à fonctionner efficacement même en cas de pannes ou d'interruptions dans certaines parties du système est essentielle. Cependant, un système de cache qui dépend d’une seule source de vérité est vulnérable à des points de défaillance uniques et ne peut pas offrir la même résilience.
9. Difficulté à désactiver complètement le cache de requêtes
L'un des aspects les plus problématiques du cache de requêtes MySQL est la complexité et parfois l'incapacité de le désactiver complètement sans redémarrer le système. Ce problème vient de la façon dont MySQL gère les paramètres de configuration du cache de requêtes.
Dans MySQL, la configuration du Query Cache est basée sur deux paramètres principaux : query_cache_size e query_cache_type. Le paramètre query_cache_size détermine la quantité de mémoire allouée au cache de requêtes, tandis que query_cache_type établit un comportement de mise en cache (activé, désactivé ou à la demande).
Théoriquement, la mise query_cache_size un 0 devrait désactiver le cache de requêtes car aucune mémoire ne serait allouée à cet effet. Toutefois, la réalité est plus complexe. Même réglage query_cache_size à 0, certaines structures internes du Query Cache restent actives et continuent de consommer des ressources, quoique dans une moindre mesure. De plus, le paramètre query_cache_type continue d'influencer le comportement du système : s'il est défini sur une valeur qui active la mise en cache, MySQL conservera certaines fonctionnalités du cache de requêtes actives, telles que la vérification des résultats mis en cache.
De plus, la désactivation du cache de requêtes n'est pas instantanée pour toutes les connexions à la base de données. Les connexions qui existaient lorsque les paramètres ont été modifiés peuvent continuer à utiliser le comportement de mise en cache précédent jusqu'à ce qu'elles soient redémarrées ou recréées. Cela signifie que l'effet de toute modification apportée aux paramètres de configuration du cache de requêtes n'est pas appliqué uniformément en temps réel.
Ces particularités dans la gestion du cache de requêtes peuvent entraîner de la confusion et des difficultés dans la gestion des performances du système, en particulier dans des environnements complexes ou dans des situations où une désactivation rapide et complète de la mise en cache est requise. Le résultat est que, dans de nombreux cas, la seule solution pour désactiver complètement le cache de requêtes et garantir que toutes les connexions respectent ce paramètre est de redémarrer le serveur MySQL. Bien entendu, cette exigence de redémarrage peut entraîner des temps d’arrêt et des interruptions de service, problématiques dans les environnements de production où la haute disponibilité est essentielle.
Alternatives au cache de requêtes MySql
Heureusement, il existe de nombreuses alternatives efficaces au cache de requêtes MySQL. Une première option implique l’utilisation de mappages objet-relationnels (ORM) modernes, dont beaucoup incluent déjà des implémentations de mise en cache. Bien que la qualité de ces mécanismes de mise en cache puisse varier considérablement, ils offrent dans de nombreux cas des performances supérieures à celles du cache de requêtes de MySQL. Des ORM encore moins efficaces peuvent être plus adaptés dans certains contextes. De plus, pour ceux qui utilisent un ORM sans fonctionnalité de mise en cache intégrée, il existe toujours la possibilité de développer votre propre mécanisme de mise en cache personnalisé.
Une autre chose à considérer est le manque de contrôle sur les requêtes mises en cache et leur durée dans le système de mise en cache de MySQL. La création d'un mécanisme de mise en cache personnalisé peut apporter une solution à ce problème, permettant une plus grande flexibilité et spécificité. Cependant, développer un système de mise en cache à partir de zéro peut s’avérer complexe et nécessiter des efforts importants.
Une alternative pratique consiste à utiliser ProxySQL, une solution qui peut être installée avec l'application (par exemple, dans un conteneur side-car si vous utilisez Docker). ProxySQL permet une configuration détaillée de la mise en cache, y compris la possibilité de spécifier les requêtes à mettre en cache ou celles à exclure. La fonctionnalité de prise en charge des expressions régulières dans ProxySQL est particulièrement utile : elle vous permet de mettre en cache uniquement les requêtes les plus lourdes, celles avec plusieurs jointures, tout en gardant à jour les requêtes impliquant des tables uniques.
Par exemple, lors d'une expérience professionnelle antérieure, nous nous sommes fortement appuyés sur la mise en cache ProxySQL. L'entreprise utilisait PrestaShop, qui n'était pas particulièrement efficace en matière de gestion de base de données avec sa requête d'indexation de catégories, impliquant jusqu'à 8 tables différentes et rendant impossible la mise en cache dans MySQL. Pour compliquer encore la situation, la base de données PrestaShop contenait un catalogue de plus de 5 millions de produits, qui étaient inclus dans la requête de catégorie pour éviter les catégories vides. En ajoutant cette requête à ProxySQL avec un Time To Live (TTL) de 4 heures (les catégories changent rarement !) nous avons pu réduire considérablement la charge sur la base de données, passant de 64 cœurs à 12.
conclusion
Examiner ces 10 raisons pour lesquelles le cache de requêtes est généralement désactivé par les experts MySQL illustre une tendance vers l'innovation et l'adaptation dans la gestion des bases de données. Cette désactivation est souvent le résultat d'une analyse réfléchie, visant à optimiser les performances et à exploiter le potentiel de MySQL dans des scénarios modernes et dynamiques. Comme le souligne la présentation que j'ai préparée pour un collègue et dont cet article représente la substance écrite, la technologie évolue et nos stratégies doivent évoluer avec elle.
Certes, il existe des cas où Query Cache peut encore s’avérer utile et améliorer les performances, mais ce sont des situations spécifiques et bien identifiées. Pour chaque scénario dans lequel Query Cache peut sembler être la bonne solution, il existe plusieurs alternatives plus flexibles et plus performantes prêtes à le remplacer. Ces alternatives répondent non seulement mieux aux besoins actuels mais sont également conçues pour s’adapter à l’évolution future des environnements informatiques.
Si vous cherchez à optimiser l'utilisation efficace de MySQL et avez besoin de conseils pour naviguer parmi les options disponibles, notre équipe d'assistance technique et système est là pour vous aider. Avec une spécialisation en hébergement Linux et en ingénierie système, nous sommes experts dans l'optimisation de CMS tels que WordPress, Joomla, Drupal et de plateformes de commerce électronique telles que WooCommerce, Magento et PrestaShop. Que vous cherchiez à améliorer les performances de votre base de données MySQL ou à adopter une stratégie de mise en cache personnalisée, nous pouvons vous offrir les conseils et l'assistance technique nécessaires pour vous aider à atteindre vos objectifs. Contactez-nous pour découvrir comment nous pouvons soutenir l'efficacité et la croissance de votre environnement MySQL.
