it-swarm.com.de

Wann wird SQL_NO_CACHE verwendet?

Ich bin gerade dabei, meine Abfragen durchzugehen, und ich habe Artikel darüber gelesen, wie Sie SQL_NO_CACHE in SELECT-Abfragen verwenden sollten. Das hat mich verwirrt, weil jeder Artikel am Ende eine andere Schlussfolgerung darüber hat, wann er verwendet wird. Ein Blog, das ich gelesen habe, sagte, Sie sollten dies verwenden, wenn Sie identische Abfragen haben und eindeutig sind. In einem anderen Blog habe ich gelesen, dass Sie es verwenden sollten, wenn Sie Informationen extrahieren müssen, die sich niemals ändern.

Kann jemand erklären, wann dies eine gute Praxis ist? Ich weiß, dass es schon früher gefragt wurde, aber das Lesen vieler Artikel hat nicht geholfen, vor allem wenn Leute sagen, dass sie diese Methode in verschiedenen Situationen anwenden. Ich habe einige theoretische Situationen gemacht, kann mir jemand sagen, ob es sinnvoll ist, SQL_NO_CACHE zu verwenden. Vielen Dank und ich entschuldige mich für eine wiederholte Frage. Ich bin nur sehr verwirrt.

  1. Angenommen, eine Website speichert ihre Konfiguration (d. H. Name der Site, Site-Beschreibung, Schlüsselwörter), und auf jeder Seite wird eine Abfrageanforderung erstellt, um diese Informationen zu extrahieren, wenn sie auf jeder Seite erforderlich sind.

  2. Sie wählen eine userID während einer Anmeldungsüberprüfung aus. Die Abfrage wird nur während des Anmeldeprozesses ausgeführt.

  3. Sie wählen einige Daten aus der Tabelle a aus, um ein Feld in der Tabelle b zu aktualisieren. Sollten Sie SQL_NO_CACHE für die Auswahl für die Tabelle a verwenden?

Vielen Dank.

18
user2738336

SQL_NO_CACHE


Fügen Sie einfach SQL_NO_CACHE nach dem SELECT-Teil der SELECT-Anweisung und vor der Feldliste hinzu. Die erste Abfrage unten verwendet den Abfrage-Cache, wenn er aktiviert ist und die Abfrage zwischengespeichert ist:

SELECT * FROM table WHERE search= 'keyword'; //lets take 1ms

Die zweite Abfrage unten verwendet den Abfrage-Cache nicht:

SELECT SQL_NO_CACHE * FROM table WHERE search= 'keyword'; //lets take ~0.2ms at 2nd time

Dies ist insbesondere beim Benchmarking einer Abfrage hilfreich. Wenn der Abfrage-Cache aktiviert ist, obwohl die erste Abfrage einige Zeit dauern kann, sind die zweite und die folgenden Abfragen nahezu sofort. Mit SQL_NO_CACHE können Sie sicher sein, dass der Abfrage-Cache nicht verwendet wird, und die Ergebniszeiten sicher vergleichen. Der Hinweis SQL_NO_CACHE deaktiviert den eingebauten Abfrage-Caching-Mechanismus von MySQL für eine bestimmte Abfrage. Sie können MySQL dabei helfen, den Abfrage-Cache effizienter zu gestalten, indem Sie diesen Hinweis für Abfragen verwenden, die sehr dynamisch sind (z. B. bei der Stichwortsuche oder bei einem Bericht, der nur nachts ausgeführt wird) ist für diesen Befehl nicht erforderlich.

was für SQL_CACHE und SQL_NO_CACHE?

Die Optionen SQL_CACHE und SQL_NO_CACHE beeinflussen das Zwischenspeichern von Abfrageergebnissen im Abfragecache. SQL_CACHE weist MySQL an, das Ergebnis im Abfrage-Cache zu speichern, wenn es zwischengespeichert werden kann und der Wert der Systemvariablen query_cache_type 2 oder DEMAND ist. Bei SQL_NO_CACHE verwendet der Server den Abfragecache nicht. Es überprüft weder den Abfrage-Cache, ob das Ergebnis bereits zwischengespeichert ist, noch speichert es das Abfrageergebnis. (Aufgrund einer Einschränkung im Parser muss vor dem SQL_NO_CACHE-Schlüsselwort ein Leerzeichen vorangestellt werden. Ein Nicht-Leerzeichen, wie z. B. ein Zeilenvorschub, veranlasst den Server, den Abfrage-Cache zu überprüfen, ob das Ergebnis bereits zwischengespeichert ist. 

NO_CACHE kann meiner Meinung nach verwendet werden, wenn 'CACHE' aktiviert ist und die Daten in der Datenbank dynamisch aktualisiert werden, dh, auf den Datenbankdatencache kann nicht Verlass sein, z Möglichkeit einer Änderung der Daten

Updates nützlicher Szenarien


1) Zwingen Sie, den Cache nicht zum Testen der Abfrage zu verwenden

8
7-isnotbad

Um Ihre Frage beantworten zu können, müssen Sie zunächst verstehen, wie der MySQL-Abfrage-Cache funktioniert. Einen sehr guten Artikel dazu finden Sie hier . Einer der wichtigsten Aspekte ist, dass der Cache mit den Daten synchronisiert wird :

Der Abfrage-Cache gibt keine veralteten Daten zurück. Wenn Tabellen geändert werden, werden alle relevanten Einträge im Abfrage-Cache Geleert.

In Ihren Anwendungsfällen finde ich keinen wirklichen Grund, den Abfrage-Cache nicht mit SQL_NO_CACHE zu verwenden. Es gibt Gründe wie das Erstellen eines Profils oder das Vermeiden des Schreibens von Big Data in einen begrenzten Abfrage-Cache für die Verwendung dieser Option, aber ich sehe das hier nicht.

4
Bjoern

Die offensichtlichste Zeit, zu der ich das Caching unterdrücken möchte, ist, wenn ich die Abfrageergebnisse nicht im Cache speichern möchte (offensichtlich?). 

Wenn ich nur einmal eine Abfrage ausführen werde, hat es keinen Sinn, Daten, die sich derzeit im Cache befinden, zu verschieben, um Platz für Daten zu schaffen, die niemals aus dem Cache abgerufen werden.

Im zweiten Szenario möchte ich eine Abfrage mit niedriger Priorität ausführen, z. Erstellen eines Berichts oder einer Teilsicherung - wenn die Leistung meiner Abfrage nicht wichtig ist, es jedoch wichtig ist, dass sie für die anderen Ereignisse in der Datenbank minimal störend ist (es gibt einige Probleme im Zusammenhang mit dem Zugriff auf den Cache-Zugriff).

Ein drittes Szenario ist, wenn es lots von einfachen, einzelnen Tabellenauswahlabfragen gibt, die sehr kleine Datensätze zurückgeben (z. B. unter Verwendung von trivialem ORM). In diesem Szenario ist die Verwendung von Abfrage-Caching wahrscheinlich langsamer als die Umgehung der gesamten Abfrage. Das DBMS verwendet mehr Zeit für die Verwaltung des Abfrage-Caches als das Lesen der Daten aus dem Pufferpool/System-Cache.

Wie Tot sagt, verzerrt der Cache jedes Profiling/Benchmarking - der Abfrage-Cache ist jedoch nicht der einzige Ort, an dem die Daten gepuffert/zwischengespeichert werden.

Sie wählen einige Daten aus Tabelle a aus, um ein Feld in Tabelle b zu aktualisieren. Sollten Sie SQL_NO_CACHE für die Auswahl für Tabelle a verwenden?

Nein. Der Cache wird automatisch ungültig, wenn die zugrunde liegenden Daten geändert werden (von denen der Großteil der Kosten für einfache Abfragen stammt).

4
symcbean

Ich habe es nur beim Profilieren von Abfragen verwendet (EXPLAIN extended...).

Wenn Sie eine Abfrage mehrmals ausführen (ein sehr wichtiger Importschritt zum "Aufwärmen" des Servers), wird diese zwischengespeichert, sodass der Profiler falsche Ergebnisse ausgibt.

Je nach Situation verwende ich auch:

SET SESSION query_cache_type = OFF

1
Toto