Nous avons mis à niveau vers MySQL 5.6 et commençons à voir le chargement du serveur db augmenter de manière significative, et nous avons finalement découvert que le query_cache_typedémarrage par défaut était à partir de 5.6.

Nous l'avons à nouveau activé et nous voyons la charge diminuer, pourquoi cette valeur est désactivée par défaut à partir de MySQL 5.6? Je ne vois pas le problème en l'activant.

Vous avez besoin de l'histoire d'InnoDB pour comprendre pourquoi. Ça y est:

HISTOIRE DE GUERRE

InnoDB et le cache de requêtes sont en état de guerre constant. InnoDB a tendance à être très lourd lors de l'inspection des modifications dans le pool de tampons InnoDB, puis de recouper le cache de requêtes pour les mêmes modifications.

TRAITÉ DE PAIX

Avant MySQL 5.0, le cache de requêtes était désactivé pour InnoDB. Maintenant, InnoDB interagit avec lui. Pour simplifier les choses, vous pouvez simplement désactiver le cache de requête en définissant query_cache_size sur 0.

Selon la documentation MySQL sur query_cache_time

Si le serveur est démarré avec query_cache_type défini sur 0, il n'acquiert pas du tout le mutex de cache de requête, ce qui signifie que le cache de requête ne peut pas être activé au moment de l'exécution et qu'il y a une surcharge réduite dans l'exécution de la requête.

CONDITIONS DE REMISE

La définition de query_cache_size à 0 n'est pas une solution universelle .

La raison de la guerre, en premier lieu, est les frais généraux. InnoDB inspectera toujours les modifications. Un cache de requête plus grand rendra InnoDB plus difficile à travailler. La désactivation du cache de requête permet à InnoDB et au cache de requête d'être satisfaits. Cependant, vous (le développeur / DBA) pourriez être une victime de cette guerre par de mauvaises performances de requête, même avec un tel traité de paix en place.

Selon les éléments suivants

• Charge de travail
• Fréquence des changements
• Fréquence de lecture des mêmes données

vous devez définir query_cache_size sur le nombre qui, selon vous, augmente les performances (cela revient à démarrer un mouvement clandestin).

ÉPILOGUE

Dans le cas où vous vous demandez où j'ai trouvé cette histoire de guerre, veuillez voir mon ancien post

• Sep 05, 2012: La surcharge d'invalidation fréquente du cache de requêtes en vaut-elle la peine?

Lisez-le attentivement car j'ai appris cela des pages 209-215 de High Performance MySQL (2nd Edition)

J'ai recommandé de désactiver le cache de requêtes à d'autres avant

• Sep 25, 2013: invalidation des entrées du cache de requête (clé)
• Sep 26, 2013: la valeur de hit du cache de requête ne change pas dans ma base de données
• Dec 23, 2013: MySQL avec une utilisation élevée du processeur et de la mémoire

REMARQUE: je me rends compte que la question portait sur le query_cache_type . Cela a un effet sur le cache de requêtes. La désactivation du cache écrase la domination d'InnoDB sur lui. La définition manuelle de query_cache_type oblige simplement le développeur / DBA à réfléchir attentivement au type de requêtes que le cache de requêtes rencontrera.

J'ai un article de blog expliquant pourquoi c'est ici .

La version courte: le cache de requêtes provoque des problèmes d'évolutivité sur les machines multicœurs. Il est donc désormais désactivé par défaut.

Pour compléter les réponses, la pression d'Oracle pour «remplacer» la fonctionnalité de cache de requête est l' intégration memcached .