web-dev-qa-db-fra.com

Pourquoi mysql supprime le cache de requêtes dans la version 8.0?

Pourquoi mysql supprime le cache de requêtes dans la version 8.0?

mysqlquery-cachemysql-8.0
9
shaoyihe

Il y a un détail blog de l'équipe du serveur MySQL à ce sujet, où Matt Lord dit:

Le cache de requêtes est désactivé par défaut depuis MySQL 5.6 (2013) car il est connu qu'il ne s'adapte pas aux charges de travail à haut débit sur les machines multicœurs.

Nous avons examiné les améliorations que nous pourrions apporter au cache de requêtes par rapport aux optimisations que nous pourrions apporter pour améliorer toutes les charges de travail.

Bien que ces choix eux-mêmes soient orthogonaux, les ressources d'ingénierie sont limitées. C'est-à-dire que nous changeons de stratégie pour investir dans des améliorations plus généralement applicables à toutes les charges de travail.

9
danblack

Bon débarras !!!

C'est un défi pour la plupart des développeurs de bases de données d'estimer correctement la taille des jeux de résultats les plus courants dans leurs applications. Avoir un grand cache de requêtes n'était qu'un gros bandage pour cela.

Il y a une raison plus importante qui préfigurait la disparition du cache de requêtes. Il y a quatre ans, j'ai répondu au message Pourquoi query_cache_type est désactivé par défaut à partir de MySQL 5.6? . En bref, le cache de requêtes inspectait toujours le pool de tampons InnoDB pour rechercher les modifications. Vous pouvez le trouver sur Pages 209-215 de High Performance MySQL (2nd Edition) .

Je l'ai mentionné au fil des ans:

Cache de requête RIP !!!

8
RolandoMySQLDBA

(Je suis d'accord avec l'autre réponse, mais voici ma valeur de 2 cents.)

Telle que mise en œuvre, ...

  • Le QC ne peut pas fonctionne avec Galera ou la réplication de groupe, les deux obtenant plus de traction dans l'arène HA.

  • Quand query_cache_size est devenu grand, il est devenu moins efficace. Cela est dû à l'inefficacité de la "taille". (Remarque: Aurora l'a réimplémenté et semble avoir résolu ce problème.)

  • Il y a un overhead dans everySELECT car il ne sait pas si le QC entrera en jeu. Il y a des décennies, ce chiffre était estimé à 11%. Jusqu'à se débarrasser du QC, la seule solution était de faire les deuxquery_cache_size = 0etquery_cache_type = 0 dans le fichier de configuration. (Peu de gens ont réalisé que les deux étaient nécessaires.)

  • Dans le serveur de production typique, les insertions se produisent fréquemment. Étant donné que chaque insert a provoqué un élagage de toutes entrées pour ces tables, le QC était pratiquement inutile pour ces tables.

  • Peut-être que 95% des centaines de systèmes que j'ai examinés pour des problèmes de performances sont mieux sans le QC.

4
Rick James