MySQL 8.0 : l'équipe MySQL Server annonce le retrait du support de Query Cache

MySQL 8.0 : l'équipe MySQL Server annonce le retrait du support de Query Cache,
qui présente des limitations au niveau de l'évolutivité

Le cache de requête MySQL est un cache de résultats de requête. Il compare les requêtes entrantes qui commencent avec SEL à une table de hachage et, s’il y a une correspondance, retourne les résultats de l'exécution précédente de la requête. Il existe certaines restrictions :

• la requête doit correspondre octet par octet (le cache de la requête évite l'analyse) ;
• l'utilisation de fonctionnalités non déterministes entraînera que la requête ne soit pas mise en cache (y compris les tables temporaires, les variables utilisateur, RAND (), NOW () et les UDF) ;
• le cache de requêtes a été conçu pour ne pas générer des résultats obsolètes. Toute modification apportée aux tables sous-jacentes entraîne l'invalidation de tous les caches pour ces tables ;
• il existe des restrictions quant à l’utilisation du cache pour InnoDB (pour respecter MVCC, alors que vous avez une transaction ouverte, le « cache » pourrait ne pas représenter les données dans la vue attendue).

Cependant, comme l’a noté René Cannaò, le fondateur de ProxySQL, « Bien que MySQL Query Cache ait été conçu pour améliorer les performances, il a de graves problèmes d'évolutivité et peut facilement devenir un grave goulot d'étranglement .»

Et de continuer en assurant que « Le cache de requête ProxySQL peut augmenter considérablement les performances pour certaines charges de travail spécifiques : lire des charges de travail intensives avec beaucoup de résultats qui peuvent être mis en cache. ProxySQL permet également de décentraliser la couche de mise en cache et de déplacer le cache du serveur de base de données et plus près de l'application. »

Morgan Tocker, Product Manager de MySQL Server, a expliqué que le cache de la requête a été désactivé par défaut depuis MySQL 5.6 (2013), car il y a des problèmes connus d’évolutivité avec des charges de travail à haut débit sur les machines multicore comme l’ont expliqué René Cannaò, Stewart Smith et Domas Mituzas.

En supposant que l'évolutivité puisse être améliorée, le facteur limitant du cache de requête est que puisque seules les requêtes qui vont dans le cache verront une amélioration, il est peu probable d'améliorer la prévisibilité des performances. Il reste persuadé que réduire la variabilité des performances est souvent plus important que l'amélioration du débit maximal.

Aussi, l’équipe a indiqué être d’accord avec la recherche réalisée par Jiamin Huang, Barzan Mozafari, Grant Schoenebeck, Thomas F. Wenisch à l'Université du Michigan, Ann Arbor. « Nous avons examiné les améliorations que nous pourrions faire pour interroger le cache par rapport aux optimisations que nous pourrions apporter qui impliqueraient des améliorations à toutes les charges de travail. »

« Bien que ces choix eux-mêmes soient orthogonaux, les ressources d'ingénierie sont finies. C'est-à-dire que nous changeons de stratégie pour investir dans des améliorations qui sont plus généralement applicables à toutes les charges de travail. Nous sommes également d'accord avec la conclusion de René selon laquelle la mise en cache offre le plus grand avantage lorsqu'il est rapproché du client. »

Autant de raisons qui ont poussé l’équipe à abandonner le support du Query Cache dans MySQL 8.0 : « Avec les limitations actuelles notées, le cache de requête continuera à être pris en charge pour la durée de vie de MySQL 5.7. MySQL 8.0 ne prend pas en charge le cache de la requête, et lors de la mise à niveau, les utilisateurs seront encouragés à utiliser soit la réécriture de la requête côté serveur, soit ProxySQL en tant que cache man-in-the-middle. »

Même si l’équipe s’attend à ce que cette modification affecte uniquement un petit nombre d'utilisateurs, elle reste disposée à échanger avec tous les développeurs qui seront concernés par cette mesure.

Source : blog MySQL Server