Warum MySQL Abfrage-Cache in Version 8.0 entfernen?

mysql query-cache mysql-8.0

— shaoyihe
quelle

Dies war der BESTE Gefallen, den jemand für die Reduzierung der pro Minute verwendeten CPU-Zyklen auf Ihrem Server tun konnte.

— Wilson Hauck

@ WilsonHauck Für kleine Datenbanken ja. Und großartig, wenn MySQL-Renditen in CPU / Zeit vorhersehbarer sind. Wenn eine Zählung (*) in einer großen Tabelle jedoch 2-3 Stunden dauern kann, um den Abfrage-Cache abzuschließen, kann diese Zeit auf einige Millisekunden verkürzt werden. Mann in den mittleren Caches sind kein Ersatz, sie wissen nicht, ob sich die Daten geändert haben. Angesichts der Tatsache, dass es für riesige Datenbanken eine fast fatale Entscheidung war.

— John

@john Post Textergebnisse von SHOW CREATE TABLE (yourtablename); und ich werde etwas vorschlagen, das deutlich unter 2-3 Stunden liegt, um Ihre Zeilenanzahl zurückzugeben.

— Wilson Hauck

@ WilsonHauck Ich habe Dutzende solcher Tabellen auf vielen Servern, es spielt kaum eine Rolle, welche Struktur Sie verwenden. Hier ein Beispiel pastebin.com/MHVACAny Füllen Sie es mit 1 Milliarde Zeilen und versuchen Sie, eine schnelle Zählung mithilfe eines Index ohne Abfrage-Caching durchzuführen. Beim Abfrage-Caching ist es eine Frage von Millisekunden, ohne dass es wahrscheinlich eine halbe bis eine Stunde pro Zählung gibt. Aktualisieren Sie nun eine der Spalten an zufälligen Stellen 1 Milliarde Mal mit unterschiedlichen Werten, und Sie werden feststellen, dass sich der Index auf 4 bis 5 Stunden verschlechtert (linearer Leistungsverlust bei Aktualisierungen). (Der zweite Teil ist eine eigenständige Ausgabe von innodb, hier nicht fair :)

— John

@ John Was sind die Ergebnisse und nnnn sec mit dieser Abfrage? SELECT COUNT (scs_id) von x_full; ?

— Wilson Hauck

Antworten:

Es gibt eine detaillierte Blog des MySQL-Serverteams 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, im Vergleich zu Optimierungen, die 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.

— Danblack
quelle

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 Niedergang des Abfragecaches vorwegnahm. 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 den Seiten 209-215 von High Performance MySQL (2nd Edition). .

Ich habe das im Laufe der Jahre erwähnt:

Sep 05, 2012: Lohnt sich der Aufwand für die häufige Ungültigmachung des Abfragecaches jemals?
Sep 25, 2013: Ungültigmachen von Abfrage-Cache-Einträgen (Schlüssel)
Sep 26, 2013: Der Trefferwert des Abfrage-Cache ändert sich in meiner Datenbank nicht
Dec 23, 2013: MySQL mit hoher CPU- und Speicherauslastung

RIP-Abfrage-Cache !!!

— RolandoMySQLDBA
quelle

Ich bin damit einverstanden, dass der Abfrage-Cache ein Verband war, vor allem, weil die Anzahl auf innodb so langsam war. Abfragen und Anwendungen waren in der Antwortzeit völlig unvorhersehbar. Sie können Millisekunden bis Stunden für dieselbe Abfrage anzeigen, je nachdem, ob sie zwischengespeichert wurde oder nicht. Zumindest war es jedoch ein Verband. Jetzt blutest du :)

— John

Die Qualitätskontrolle existierte, bevor InnoDB existierte. Die alte Geschichte, die ich hörte (vielleicht um 2002), war, dass die Qualitätskontrolle hinzugefügt wurde, um einen Benchmark mit MyISAM zu gewinnen.

— Rick James

@ RickJames Hah klingt plausibel, obwohl es betrügt Mysql braucht meiner Meinung nach mehr als alles andere: vollständiges Multithreading für alle Arten von Abfragen. Sie scheinen in diese Richtung zu arbeiten (ein bisschen hier, ein bisschen dort), aber es hätte schon vor langer Zeit implementiert werden müssen. Das wäre auch ein Killer-Feature gewesen, um nicht nur zu gewinnen, sondern viele Arten von Benchmarks zu "besitzen"

— John

@ John - MySQL 8.0.17 (?) Haben einige parallele Abfragen. Ich bin noch nicht aufgeregt. Ein Produkt namens "Shard Query" gibt es schon lange; es zeigt, dass Parallelität typischerweise nur die Hälfte der theoretischen Kapazität ergibt. (z. B. 8 Kerne ergeben nur eine 4-fache Beschleunigung.) Beachten Sie außerdem, dass die meisten E / A keine Parallelität aufweisen, es sei denn, Sie haben bestimmte RAID-Setups.

— Rick James

@ John - und ... "Vor langer Zeit" Server hatten einen, vielleicht zwei CPU-Kerne. Parallelität war also nicht sehr nützlich. Sobald mehrere Kerne vorhanden waren, gab es eine Reihe von Aktivitäten, um die Mutexe zu bereinigen, sodass mehrere Verbindungen parallel funktionieren konnten.

— Rick James

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

Wie implementiert, ...

Die Qualitätskontrolle kann nicht mit Galera oder Gruppenreplikation arbeiten, die beide in der HA-Arena mehr Zugkraft erhalten.
Wenn es query_cache_sizegroß wurde, wurde es weniger effizient. Dies ist auf Ineffizienzen beim "Beschneiden" zurückzuführen. (Hinweis: Aurora hat es erneut implementiert und scheint dieses Problem behoben zu haben.)
Jeder hat einen Overhead, SELECTweil er 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, beides query_cache_size = 0 und query_cache_type = 0 die Konfigurationsdatei auszuführen. (Nur wenige Leute erkannten, dass beide benötigt wurden.)
Auf dem typischen Produktionsserver treten häufig Einfügungen auf. Da bei jeder Einfügung alle Einträge für diese Tabelle (n) gelöscht wurden, 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.

— Rick James
quelle