Detaillierte Erläuterung der Verwendung des MySQL-Auswahl-Cache-Mechanismus

Der MySQL-Abfragecache ist standardmäßig aktiviert. Bis zu einem gewissen Grad kann dies den Abfrageeffekt verbessern, ist aber möglicherweise nicht die beste Lösung. Wenn viele Änderungen und Abfragen vorgenommen werden, führt der durch die Änderungen verursachte Cache-Fehler zu einem hohen Overhead für den Server. Sie können den Cache-Schalter über query_cache_type [0 (AUS) 1 (EIN) 2 (ANFORDERUNG)] steuern.

Es ist zu beachten, dass der MySQL-Abfragecache zwischen Groß- und Kleinschreibung unterscheidet, da der Abfragecache im Speicher mit einer HASH-Struktur abgebildet wird. Die Grundlage des HASH-Algorithmus sind die Zeichen, aus denen die SQL-Anweisung besteht, sodass jede Änderung an der SQL-Anweisung erneut zwischengespeichert wird. Dies ist auch der Grund, warum bei der Projektentwicklung Standards für das Schreiben von SQL-Anweisungen festgelegt werden sollten.

1. Wann sollte ich cachen?

a) Der Inhalt des MySQL-Abfragecaches ist der Ergebnissatz von select. Der Cache verwendet die vollständige SQL-Zeichenfolge als Schlüssel und berücksichtigt Groß- und Kleinschreibung, Leerzeichen usw. Das heißt, die beiden SQL-Anweisungen müssen vollständig konsistent sein, um einen Cache-Treffer zu verursachen.

b) Die vorbereitete Anweisung wird das Ergebnis niemals zwischenspeichern, selbst wenn die Parameter genau gleich sind. Es wird gesagt, dass es nach 5.1 verbessert wird.

c) Wenn die Where-Bedingung bestimmte Funktionen enthält, werden diese nie zwischengespeichert, wie z. B. current_date, now usw.

d) Wenn Funktionen wie das Datum Daten in Stunden oder Tagen zurückgeben, ist es am besten, diese zuerst zu berechnen und dann weiterzugeben.
select * from foo where date1=current_date – wird nicht zwischengespeichert
select * from foo where date1='2008-12-30' – zwischengespeichert, korrekter Ansatz

e) Ein zu großer Ergebnissatz wird nicht zwischengespeichert (< query_cache_limit)

2. Wann ist eine Ungültigkeitserklärung erforderlich?

a) Sobald eine beliebige Zeile der Tabellendaten geändert wird, werden alle mit der Tabelle verbundenen Caches sofort ungültig.

b) Warum nicht schlauer sein und feststellen, ob es sich bei dem geänderten Inhalt um Cache-Inhalt handelt? Da die Analyse des Cache-Inhalts so komplex ist, muss der Server auf maximale Leistung abzielen.

3. Leistung

a) Cache verbessert die Leistung nicht immer und in allen Situationen

Bei einer großen Anzahl von Abfragen und Änderungen kann der Cache-Mechanismus zu Leistungseinbußen führen. Denn jede Änderung führt dazu, dass das System Cache-Ungültigkeitsoperationen durchführt, was einen erheblichen Mehraufwand zur Folge hat.

Darüber hinaus wird der Zugriff auf den Systemcache durch eine einzige globale Sperre gesteuert, und eine große Anzahl von Abfragen wird blockiert, bis die Sperre aufgehoben wird. Gehen Sie also nicht einfach davon aus, dass die Einrichtung eines Caches mit Sicherheit zu Leistungsverbesserungen führt.

b) Große Ergebnismengen werden nicht zwischengespeichert.

Ein zu großer Ergebnissatz wird nicht zwischengespeichert, aber MySQL kennt die Länge des Ergebnissatzes nicht im Voraus. Daher kann es nur warten, bis der Cache nach dem Zurücksetzen des Satzes den kritischen Wert query_cache_limit erreicht, und den Cache dann einfach verwerfen. Dies ist kein effizienter Vorgang. Wenn der Qcache_not_cached-Status im MySQL-Server zu groß ist, können Sie bei potenziell großen Ergebnismengen explizit die SQL_NO_CACHE-Steuerung zum SQL hinzufügen.
query_cache_min_res_unit = (Abfrage-Cache-Größe – Qcache_freier_Speicher) / Qcache_Queries_in_cache

4. Speicherpoolnutzung

Der MySQL-Abfragecache verwendet Speicherpooltechnologie, um die Speicherfreigabe und -zuweisung selbst zu verwalten, anstatt dies über das Betriebssystem zu tun. Die vom Speicherpool verwendete Grundeinheit ist ein Block variabler Länge, und ein Ergebnissatz-Cache verknüpft diese Blöcke über eine verknüpfte Liste. Denn beim Speichern des Ergebnissatzes weiß man nicht, wie groß der Ergebnissatz letztendlich sein wird. Die Mindestlänge eines Blocks beträgt query_cache_min_res_unit, und der letzte Block eines Ergebnissatzes führt einen Trimmvorgang aus.

Der Abfragecache spielt eine sehr wichtige Rolle bei der Verbesserung der Datenbankleistung.

Auch die Einrichtung ist sehr einfach, es müssen nur zwei Zeilen in die Konfigurationsdatei geschrieben werden: query_cache_type und query_cache_size, und schon ist der Abfrage-Cache von MySQL sehr schnell! Und sobald ein Treffer gefunden wird, wird er direkt an den Client gesendet, was viel CPU-Zeit spart.

Natürlich wirken sich Nicht-SELECT-Anweisungen auf den Cache aus und können dazu führen, dass die Daten im Cache verfallen. Eine teilweise Tabellenänderung durch eine UPDATE-Anweisung macht alle gepufferten Daten für die Tabelle ungültig. Dabei handelt es sich um eine Maßnahme, die MySQL aus Leistungsgründen nicht ergreift. Denn wenn bei jedem UPDATE die geänderten Daten geprüft und anschließend ein Teil des Puffers entnommen werden muss, erhöht sich die Komplexität des Codes.

query_cache_type 0 bedeutet, dass kein Cache verwendet wird, 1 bedeutet, dass Cache verwendet wird, und 2 bedeutet, dass er nach Bedarf verwendet wird.

Die Einstellung 1 bedeutet, dass die Pufferung immer wirksam ist. Wenn keine Pufferung erforderlich ist, müssen Sie die folgende Anweisung verwenden:

Der Code lautet wie folgt

Wählen Sie SQL_NO_CACHE * aus meiner_Tabelle, wobei ...

Wenn der Wert auf 2 gesetzt ist, müssen Sie die Pufferung aktivieren. Sie können dazu die folgende Anweisung verwenden:

Der Code lautet wie folgt

WÄHLEN SIE SQL_CACHE * AUS meiner_Tabelle, WO ...

Verwenden Sie SHOW STATUS, um den Pufferstatus anzuzeigen:

Der Code lautet wie folgt

mysql> Status wie „Qca%“ anzeigen;
+-------------------------+----------+
| Variablenname | Wert |
+-------------------------+----------+
| Qcache_queries_in_cache | 8 |
| Qcache_inserts | 545875 |
| Qcache_hits | 83951 |
| Qcache_lowmem_prunes | 0 |
| Qcache_nicht_zwischengespeichert | 2343256 |
| Qcache_freier_Speicher | 33508248 |
| Qcache_freie_blöcke | 1 |
| Qcache_total_blocks | 18 |
+-------------------------+----------+
8 Zeilen im Satz (0,00 Sek.)

Um die Trefferquote zu berechnen, müssen Sie wissen, wie viele SELECT-Anweisungen der Server ausgeführt hat:

Der Code lautet wie folgt

mysql> Status wie „Com_sel%“ anzeigen;
+---------------+---------+
| Variablenname | Wert |
+---------------+---------+
| Com_Auswahl | 2889628 |
+---------------+---------+
1 Zeile im Satz (0,01 Sek.)

In diesem Fall hat MySQL 83.951 der 2.889.628 Abfragen getroffen und nur 545.875 waren INSERT-Anweisungen. Daher ist die Summe der beiden weit entfernt von der Gesamtabfrage von 2,8 Millionen, sodass wir wissen, dass der in diesem Beispiel verwendete Puffertyp 2 ist.

Im Beispiel vom Typ 1 ist der Wert von Qcache_hits viel größer als Com_select

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.