Wann soll MySQL query_cache verwendet werden?

Bis vor kurzem habe ich den Abfragecache als ein sehr wichtiges Werkzeug zur Verbesserung der Abfrageleistung angesehen. Heute habe ich mir einen Podcast angehört , in dem es darum ging, den Abfrage-Cache auf 0 zu optimieren und eine bessere Speicher-Caching-Lösung (wie memcache.d) zu verwenden.

Sie erwähnten aber auch, dass es einige Fälle gibt, in denen query_cache hilfreich ist. Eine allgemeine Empfehlung wäre daher, es bei Bedarf aktivieren zu lassen (unter Verwendung SELECT SQL_CACHEeiner Konfigurationseinstellung query_cache_type = 2).

Meine Frage ist, unter der Annahme, dass Sie eine Caching-Lösung wie memcache.d eingerichtet haben, welche Umstände würden den query_cache optimaler machen?

Bearbeiten: Link hinzugefügt

Memcached (oder Coherence ) speichert ganze Ergebnismengen zwischen . Ein Cache in der Datenbank speichert Datenbankzeilen zwischen. Angenommen, Sie haben ein Zugriffsmuster, bei dem die Abfrage behoben ist und sich die Daten selten ändern (z select * from restaurants where location='london'. B. ). Sie können diese Abfrage bei jedem Hinzufügen eines neuen Restaurants tausende Male ausführen. Wenn Sie also die gesamte Ergebnismenge zwischenspeichern, ist es sinnvoll, jedes Mal in die Datenbank zu wechseln. Sie verfügen jedoch weiterhin über die Verwaltbarkeit und Flexibilität von RDBMS und SQL (Sie müssen nur gelegentlich den Cache rausschmeißen, wenn sich die Daten ändern). Einige Leute nennen diese Referenzdaten oder statische Daten.

Angenommen, Sie haben ein Ad-hoc-Zugriffsmuster (möglicherweise gibt es viele Optionen für Ihren Benutzer, um genau zu finden, wo er heute Abend essen möchte, aber es kommt selten vor, dass zwei Benutzer genau dieselben Einstellungen haben). Dann möchten Sie möglicherweise die Zeilen zwischenspeichern (um das Speichern auf der Festplatte zu sparen), aber jede Ergebnismenge im laufenden Betrieb im Speicher zusammenstellen. Dann möchten Sie, dass die Datenbank selbst verwaltet, was und wie sie zwischengespeichert wird. In den meisten Fällen funktioniert ein hybrider oder mehrschichtiger Ansatz am besten.

Beachten Sie, dass es auch eine dritte Art von Caching in Aktion gibt - den Dateisystem-Cache des Betriebssystems. Ich mag diese nicht, aus dem einfachen Grund, dass wenn Sie einen Block von der Festplatte lesen, dieser jetzt im Datenbank-Cache und im Dateisystem-Cache vorhanden ist, die Datenbank jedoch nichts über letzteren "weiß" und dies daher nicht kann Machen Sie etwas Kluges damit, wie sehen Sie, wie oft es verwendet wird. Aus Sicht des Datenbankadministrators wird jeglicher freie Speicherplatz auf dem System verschwendet, über das hinaus, was das Betriebssystem selbst benötigt, um zufrieden zu sein.

Ich denke, es gibt viele falsche Informationen über den Abfrage-Cache da draußen.

Der beste Fall für den Abfragecache ist, wenn Sie eine sehr große Anzahl von Zeilen untersuchen müssen, aber nur wenige an einen Client zurückgeben müssen. Eine typische Situation, in der dies häufig vorkommt, ist ein System, in dem keine ordnungsgemäße Optimierung oder Indizierung angewendet wurde.

In einer Situation, in der viele der Abfragen Primärschlüssel-Lookups sind oder auf andere Weise sehr gut optimiert sind, kann der Abfrage-Cache eine negative Skalierbarkeit verursachen. Ja, das macht alles noch schlimmer!

Der Grund dafür ist, dass das Design einige interne Sperren hinzufügt, die die Skalierung Ihres MySQL-Servers auf Multi-Core-Computern einschränken.

Der Abfrage-Cache ist eine Ursache für viele "plötzliche Verzögerungen" in MySQL - nicht alle sind offensichtlich. In Percona Server haben wir der Prozessliste einen neuen Status hinzugefügt (Warten auf Qcache-Mutex): http://www.percona.com/docs/wiki/percona-server:features:status_wait_query_cache_mutex

(Haftungsausschluss, ich arbeite für Percona.)

Ich glaube nicht, dass es hier bereits erwähnt wird, aber es ist möglich, dass der Abfrage-Cache auch die Leistung beeinträchtigt. Vielleicht wurde dies in Ihrem Podcast erwähnt. Wenn die Effizienz des Abfragecaches gering ist ( Qcache_hits / (Qcache_hits + Com_select)) und viele Abfragecache-Pflaumen ( Qcache_lowmem_prunes/Uptime) auftreten, ist es möglich, dass der Aufwand für die Verwaltung des Caches mehr kostet als Sie gewinnen.

Dieser Beitrag von Peter Zaitsev behandelt die Dinge etwas detaillierter. Im Gegensatz zu einigen Antworten hier gibt er an, dass der Cache für ganze Ergebnismengen ist. Die Stelle ist jedoch mehrere Jahre alt. Einige neuere Gedanken wurden im April veröffentlicht.

Ich hatte immer den Eindruck, dass vollständige Ergebnismengen zwischengespeichert werden, nicht wie oben erwähnt. Wenn Sie genau dieselbe Abfrage haben, wird das Parsen / Planen übersprungen und dieselbe Ergebnismenge zurückgegeben (deren maximale Größe von gesteuert wird query_cache_limit).

Wenn Sie den Abfragecache deaktiviert haben, ist in einer Umgebung mit hohem Lesezustand, in der die SELECTs sehr einfach sind, keine Sperrmechanismen aktiviert. Ich habe dies erst kürzlich mit MySQL 5.5 unter Verwendung mehrerer Pufferpools erlebt.

Wenn Sie dieselben grundlegenden Abfragen wiederholt aufrufen, müssen Sie dieselbe Abfrage nicht immer wieder analysieren, bis die Kühe nach Hause kommen. Ein kleiner Abfrage-Cache sollte in einer Umgebung mit starkem Lesevorgang ausreichen, wenn ein kleiner Satz von SELECTs verwendet wird, von denen Sie wissen, dass sie immer aufgerufen werden.

memcached ist viel praktischer für große Datenmengen in Umgebungen mit starker Lesefähigkeit. Der Abfrage-Cache ist zu diesem Zeitpunkt eine lahme Ente.