it-swarm.com.de

Warum MySQL Abfrage-Cache in Version 8.0 entfernen?

Warum MySQL Abfrage-Cache in Version 8.0 entfernen?

9
shaoyihe

Es gibt ein detailliertes Blog vom MySQL-Serverteam darüber, in dem Matt Lord sagt:

Der Abfragecache ist seit MySQL 5.6 (2013) standardmäßig deaktiviert, da bekannt ist, dass er nicht mit Workloads mit hohem Durchsatz auf Multi-Core-Computern skaliert.

Wir haben uns überlegt, welche Verbesserungen wir an der Abfrage des Cache vornehmen können, und welche Optimierungen wir vornehmen können, um Verbesserungen für alle Workloads zu erzielen.

Während diese Entscheidungen selbst orthogonal sind, sind die technischen Ressourcen begrenzt. Das heißt, wir ändern unsere Strategie, um in Verbesserungen zu investieren, die allgemeiner für alle Workloads gelten.

9
danblack

Auf Nimmerwiedersehen !!!

Für die meisten Datenbankentwickler ist es eine Herausforderung, die Größe der häufigsten Ergebnismengen in ihren Anwendungen korrekt zu schätzen. Ein großer Abfrage-Cache war dafür nur ein großer Verband.

Es gibt einen größeren Grund, der den Untergang des Abfragecaches ankündigte. Vor vier Jahren habe ich den Beitrag beantwortet Warum ist query_cache_type standardmäßig deaktiviert, ab MySQL 5.6? . Kurz gesagt, der Abfragecache hat den InnoDB-Pufferpool immer auf Änderungen überprüft. Sie finden dies auf Seiten 209-215 von High Performance MySQL (2nd Edition) .

Ich habe das im Laufe der Jahre erwähnt:

RIP-Abfrage-Cache !!!

8
RolandoMySQLDBA

(Ich stimme der anderen Antwort zu, aber hier ist mein Wert von 2 Cent.)

Wie implementiert, ...

  • Die QC kann nicht funktioniert mit Galera oder Gruppenreplikation, die beide in der HA-Arena mehr Traktion bekommen.

  • Wann query_cache_size wurde groß, es wurde weniger effizient. Dies ist auf Ineffizienzen beim "Beschneiden" zurückzuführen. (Hinweis: Aurora hat es erneut implementiert und scheint dieses Problem behoben zu haben.)

  • Es gibt einen Overhead in everySELECT, weil es nicht weiß, ob die Qualitätskontrolle ins Spiel kommt. Vor Jahrzehnten wurde dies auf 11% geschätzt. Bis zur Beseitigung der Qualitätskontrolle bestand die einzige Problemumgehung darin, beidequery_cache_size = 0ndquery_cache_type = 0 in der Konfigurationsdatei. (Nur wenige Leute erkannten, dass beide benötigt wurden.)

  • Auf dem typischen Produktionsserver treten häufig Einfügungen auf. Da each insert ein Bereinigen von all Einträgen für diese Tabelle (n) verursachte, war die Qualitätskontrolle für solche Tabellen praktisch unbrauchbar.

  • Vielleicht sind 95% der Hunderte von Systemen, die ich auf Leistungsprobleme überprüft habe, ohne die Qualitätskontrolle besser dran.

4
Rick James