Wir haben ein Upgrade auf MySQL 5.6 durchgeführt und festgestellt, dass die query_cache_typeAuslastung des Datenbankservers erheblich zugenommen hat. Schließlich haben wir festgestellt, dass standardmäßig ab 5.6 nicht mehr gestartet wird.

Wir haben es wieder aktiviert und sehen, dass das Laden abnimmt. Warum ist dieser Wert standardmäßig deaktiviert? Starten Sie ab MySQL 5.6. Ich kann das Problem nicht sehen, wenn es aktiviert ist.

Sie benötigen die Geschichte von InnoDB, um zu verstehen, warum. Hier kommt's:

KRIEGSGESCHICHTE

InnoDB und der Query-Cache befinden sich in einem ständigen Kriegszustand. InnoDB ist in der Regel sehr umständlich, wenn Änderungen im InnoDB-Pufferpool überprüft und anschließend der Abfrage-Cache auf dieselben Änderungen überprüft werden.

FRIEDENSVERTRAG

Vor MySQL 5.0 war der Abfrage-Cache für InnoDB deaktiviert. Jetzt interagiert InnoDB damit. Zur Vereinfachung können Sie den Abfrage-Cache einfach deaktivieren, indem Sie query_cache_size auf 0 setzen.

Gemäß der MySQL-Dokumentation zu query_cache_time

Wenn der Server mit dem Wert 0 für query_cache_type gestartet wird , wird der Mutex für den Abfragecache überhaupt nicht abgerufen. Dies bedeutet, dass der Abfragecache zur Laufzeit nicht aktiviert werden kann und der Aufwand für die Abfrageausführung geringer ist.

BEDINGUNGEN DER ÜBERMITTLUNG

Das Festlegen von query_cache_size auf 0 ist keine Standardlösung .

Der Grund für den Krieg liegt in erster Linie in der Luft. InnoDB prüft Änderungen immer. Ein größerer Abfragecache macht die Arbeit mit InnoDB so viel schwieriger. Wenn Sie den Abfrage-Cache deaktivieren, freuen wir uns über InnoDB und den Abfrage-Cache. Sie (der Entwickler / DBA) könnten jedoch durch schlechte Abfrageleistung ein Opfer dieses Krieges sein, selbst wenn ein solcher Friedensvertrag vorliegt.

Abhängig von Folgendem

• Arbeitsbelastung
• Häufigkeit der Änderungen
• Häufigkeit des Lesens derselben Daten

Sie sollten query_cache_size auf eine beliebige Zahl setzen, die Ihrer Meinung nach die Leistung erhöht (dies entspricht dem Starten einer unterirdischen Bewegung).

EPILOG

Falls Sie sich fragen, woher ich diese Kriegsgeschichte habe, lesen Sie bitte meinen alten Beitrag

• Sep 05, 2012: Lohnt sich der Aufwand für die häufige Ungültigmachung des Abfragecaches jemals?

Lesen Sie es sorgfältig durch, da ich dies aus den Seiten 209-215 von High Performance MySQL (2nd Edition) gelernt habe.

Ich habe empfohlen, den Abfrage-Cache zuvor für andere zu deaktivieren

• Sep 25, 2013: Ungültigmachen von Abfrage-Cache-Einträgen (Schlüssel)
• Sep 26, 2013: Abfrage-Cache-Trefferwert ändert sich in meiner Datenbank nicht
• Dec 23, 2013: MySQL mit hoher CPU- und Speichernutzung

HINWEIS: Mir ist klar, dass es sich bei der Frage um den query_cache_type handelt . Dies hat Auswirkungen auf den Abfragecache. Durch Deaktivieren des Caches wird die Dominanz von InnoDB über den Cache verringert. Wenn Sie den query_cache_type manuell festlegen, muss der Entwickler / DBA nur genau überlegen, auf welche Art von Abfragen der Abfragecache stoßen wird.

Ich habe einen Blog-Beitrag, der erklärt, warum dies hier ist .

Die Kurzversion: Der Abfragecache verursacht Skalierbarkeitsprobleme auf Mehrkerncomputern. Daher ist es jetzt standardmäßig deaktiviert.

Um die Antworten zu vervollständigen, ist das Bestreben von Oracle, die Abfrage-Cache-Funktionalität zu "ersetzen", die Integration in den Speicher .