Pourquoi query_cache_type est désactivé par défaut à partir de MySQL 5.6?
Nous avons mis à niveau vers MySQL 5.6 et commençons à voir le chargement du serveur db augmenter considérablement, et nous avons finalement découvert le query_cache_type est défini par défaut pour désactiver le démarrage à 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 que les frais généraux sont réduits lors de 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êtes 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 de 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 d'accès au cache de requête ne change pas dans ma base de donnéesDec 23, 2013: MySQL avec une utilisation élevée du processeur et de la mémoire
REMARQUE: Je me rends compte que la question concernait 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 force 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, Oracle's Push pour "remplacer" la fonctionnalité de cache de requête est intégration memcached .