Pourquoi query_cache_type est désactivé par défaut à partir de MySQL 5.6?


28

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.

Réponses:


39

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

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

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.


Salut, j'ai lu tous vos liens. En fait, j'ai essayé de désactiver à nouveau le cache de requêtes et nous constatons que le chargement augmente à nouveau de manière significative .. nous devons donc réactiver. Je ne dis pas que ce que vous dites est faux, peut-être que notre application est lue et que le cache de requêtes est très utile pour réduire le chargement .. (notre site exécute WordPress)
Yoga

3
Si seulement plus de messages SO lisaient comme ça (merci pour l'analogie amusante)! Je parie que les enfants chanceux de Rolando se font raconter des histoires au coucher MySQL comme ça tous les soirs! ;)
rinogo

2
"Pages 209-215 de High Performance MySQL (2nd Edition)" fait référence à un chapitre intitulé "Le cache de requêtes MySQL", de "Quand le cache de requêtes est utile" et jusqu'à la fin. Cela correspond aux pages 320 à 329 de la 3e édition.
Peter V. Mørch


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.