Warum ist query_cache_type ab MySQL 5.6 standardmäßig deaktiviert?


28

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.

Antworten:


39

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

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

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.


Hallo, ich habe alle deine Links gelesen. Eigentlich habe ich versucht, den Abfrage-Cache wieder zu deaktivieren, und wir sehen, dass der Ladevorgang wieder erheblich zunimmt. Deshalb müssen wir ihn wieder einschalten. Ich sage nicht, was Sie sagen, ist falsch, vielleicht nur unsere Anwendung ist schwer zu lesen und Abfrage-Cache ist sehr nützlich, um das Laden zu reduzieren .. (unsere Website läuft WordPress)
Yoga

3
Wenn nur mehr SO Posts so lesen (danke für die spaßige Analogie)! Ich wette, Rolando´s glückliche Kinder bekommen jeden Abend solche MySQL-Gutenachtgeschichten erzählt! ;)
rinogo

2
"Seiten 209-215 von High Performance MySQL (2nd Edition)" bezieht sich auf ein Kapitel mit dem Namen "Der MySQL-Abfrage-Cache", von "Wenn der Abfrage-Cache hilfreich ist" bis zum Ende. Dies entspricht den Seiten 320-329 in der 3. Auflage.
Peter V. Mørch


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.