Sélectionner une page

Fonctionnement de query_cache de MySQL

L’utilisation du mécanisme query_cache de MySQL peut se révéler être néfaste aux performances de vos requêtes.

Le fonctionnement est assez simple ( classique pour un système de cache ), MySQL enregistre un Hash des requêtes SELECT et le résultat correspondant puis fournit directement ce résultat si une requête correspondante est de nouveau exécutée.

Problématique de query_cache sur les sites web à fort trafic

Jusque là tout va bien, seulement lorsque quelque chose change dans une table ( INSERT, UPDATE, DELETE, TRUNCATE, ALTER, DROP ..  ) l’ensemble des données en cache liées de prés ou de loin à cette table est invalidé et supprimé.

Sur des bases de petites taille avec peu de requêtes/sec, cela n’a pas vraiment d’incidence, cependant sur des bases avec de gros volumes et beaucoup de requêtes l’opération de mise à jour du cache peut prendre plus de temps.

Comme il utilise le lock global , les requêtes peuvent s’empiler très rapidement ce qui va dégrader les temps de réponses de votre base données et donc de votre site web pouvant même aller jusqu’à provoquer des messages d’alerte « max connections » dans les logs bloquant complètement toute nouvelle requête.

Vous pouvez visualiser cet aspect avec la commande:

C’est dans ce cas précis que l’utilisation du query_cache se révèle plus un frein qu’autre chose, faisant augmenter les temps de réponse de l’ensemble de votre site .

Que faire

Augmenter la taille du cache ne ferait qu’empirer la situation, le mieux est tout simplement de désactiver cette fonctionnalité, en passant à 0 la valeur de query_cache_size

Le futur

Cette option est dépréciée à partir de la version MySQL 5.7.20 et complètement supprimée dans la version MySQL 8.0

Sources :