Speicherverwaltung der Speicher-EngineIn der InnoDB-Speicher-Engine wird der Pufferpool in der Datenbank vom LRU-Algorithmus (Latest Recent Used) verwaltet, d. h. die am häufigsten verwendeten Seiten stehen am Anfang der LRU-Liste und die am wenigsten verwendeten Seiten am Ende der LRU-Liste. Wenn der Pufferpool die neu gelesenen Seiten nicht speichern kann, werden zuerst die Seiten am Ende der LRU-Liste freigegeben. In der obigen Abbildung verwende ich 8 Datenseiten, um die Warteschlange darzustellen. Ich werde Sie über ihre spezifischen Funktionen auf dem Laufenden halten. In der InnoDB-Speicher-Engine beträgt die Standardgröße einer Seite im Pufferpool 16 KB. Es gibt eine Mittelpunktposition in der LRU-Liste. Die neu gelesene Datenseite wird nicht direkt an den Anfang der LRU-Liste gestellt, sondern an die Mittelpunktposition der LRU-Liste. Dieser Vorgang wird als Mittelpunkteinfügungsstrategie bezeichnet, auch bekannt als Mittelpunkteinfügungsstrategie. In der Standardkonfiguration liegt diese Position bei 5/8 der LRU-Länge, weshalb oben 8 Datenseiten verwendet werden. Das folgende Diagramm veranschaulicht den Vorgang zum Einfügen einer neuen Datenseite: Die Position des Mittelpunkts kann durch den Parameter innodb_old_blocks_pct wie folgt gesteuert werden: mysql> Variablen wie „innodb_old_blocks_pct“ anzeigen; +--------------------------+----------+ | Variablenname | Wert | +--------------------------+----------+ | innodb_old_blocks_pct | 37 | +--------------------------+----------+ Zeile im Set (. Sek.) Das Ergebnis aus dem obigen Beispiel ist 37, was bedeutet, dass die neu gelesene Seite an einer Position ungefähr 37 % vom Ende der LRU-Liste eingefügt wird, also etwa 3/8 der Distanz. In der InnoDB-Speicher-Engine werden die Seiten vor dem Mittelpunkt als neue Liste und die Seiten nach dem Mittelpunkt als alte Liste bezeichnet. Die Seiten in der neuen Liste sind die aktivsten Daten. Warum wird die Datenseite nicht einfach an den Anfang der LRU-Warteschlange gestellt?Der Grund dafür, dass die neu gelesene Datenseite nicht an den Anfang der LRU-Warteschlange gestellt wird, besteht darin, dass einige SQL-Vorgänge zum vollständigen Tabellenscan alle Hot Data aus der LRU-Warteschlange aktualisieren können, was dazu führt, dass beim nächsten Zugriff auf die Hot Data die entsprechenden Daten von der Festplatte abgerufen werden müssen, wodurch die Effizienz des Pufferpools beeinträchtigt wird. Um dieses Problem zu lösen, verwendet InnoDB einen anderen Parameter zur Verwaltung der LRU-Liste, innodb_old_blocks_time, der angibt, wie lange es dauert, bis eine Seite zum heißen Ende der LRU-Liste hinzugefügt wird, nachdem sie bis zur Mitte gelesen wurde. Wenn der oben erwähnte SQL-Vorgang ausgeführt werden muss, kann daher die folgende Methode verwendet werden, um das Löschen der Hot Data in der LRU-Liste so weit wie möglich zu verhindern. mysql> globales innodb_old_blocks_time= festlegen; Abfrage OK, Zeilen betroffen (0,00 Sek.) Dies bedeutet, dass die Daten nach 1000 Sekunden bis zum heißen Ende der LRU-Liste aktualisiert werden dürfen. Wenn in der Praxis die aktive Rate der Datenseiten über 63 % liegt, können Benutzer die Wahrscheinlichkeit des Löschens von Hotpages auch durch Festlegen von innodb_old_blocks_pct verringern. mysql> global innodb_old_blocks_pct= festlegen; Abfrage OK, Zeilen betroffen (0,00 Sek.) Wenn die Datenbank gerade gestartet wurde, ist der Inhalt von LRU leer. Zu diesem Zeitpunkt werden alle Datenseiten in die Freiliste gestellt. Wenn eine Seitenauslagerung aus dem Pufferpool erforderlich ist, prüfen Sie zunächst, ob in der Freiliste eine freie Seite verfügbar ist. Wenn ja, löschen Sie die Seite aus der Freiliste und stellen Sie sie dann in die LRU-Liste. Löschen Sie die Datenseite am Ende der LRU-Liste und weisen Sie den Speicherplatz der neuen Seite zu. Das Flussdiagramm dieses Prozesses sieht wie folgt aus: Wenn eine Seite in der LRU-Liste vom alten Teil zum neuen Teil hinzugefügt wird, wird der Vorgang, der zu diesem Zeitpunkt auftritt, als „Seite verjüngt“ bezeichnet, und der Vorgang, der aufgrund der Einstellung von innodb_old_blocks_time nicht vom alten Teil zum neuen Teil verschoben wird, wird als „Seite nicht verjüngt“ bezeichnet. Mit „show engine innodb status“ können Sie die Nutzung und den Ausführungsstatus der LRU-Liste und der Free-Liste beobachten. mysql> Engine-InnoDB-Status anzeigen\G *** *** ---------------------- PUFFERPOOL UND SPEICHER ---------------------- Insgesamt zugewiesener großer Speicher Zugewiesener Wörterbuchspeicher Pufferpoolgröße Freie Puffer Datenbankseiten Alte Datenbankseiten Geänderte Datenbankseiten Ausstehende Lesevorgänge Ausstehende Schreibvorgänge: LRU, Flush-Liste, einzelne Seite Seiten gemacht jung, nicht jung 0,00 Junge/n, 0,00 Nicht-Junge/n Gelesene, erstellte und geschriebene Seiten 0,00 Lesevorgänge/s, 0,00 Erstellungsvorgänge/s, 0,00 Schreibvorgänge/s Keine Buffer Pool-Seite seit dem letzten Ausdruck Seiten vorauslesen 0,00/s, Seiten ohne Zugriff verdrängt 0,00/s, zufälliges Vorauslesen 0,00/s LRU-Länge: , unzip_LRU-Länge: I/O-Summe[]:aktuell[], Entpack-Summe[]:aktuell[] -------------- Zeilenoperationen -------------- Abfragen innerhalb von InnoDB, Abfragen in der Warteschlange Leseansichten werden in InnoDB geöffnet Prozess-ID=, Haupt-Thread-ID=, Status: Ruhezustand Anzahl der eingefügten, aktualisierten, gelöschten und gelesenen Zeilen 0,00 Einfügungen/s, 0,00 Aktualisierungen/s, 0,00 Löschungen/s, 0,00 Lesevorgänge/s ---------------------------- ENDE DER INNODB MONITOR-AUSGABE ============================ Zeile im Satz (0,00 Sek.) Aus den obigen Ergebnissen können wir ersehen, dass die aktuelle Pufferpoolgröße insgesamt 8191 Seiten umfasst, die Größe jeder Datenseite 16 KB beträgt und die Gesamtgröße des Pufferpools 8191 * 16 KB = 128 MB beträgt, wobei „Freie Puffer“ die Anzahl der Seiten in der aktuellen Liste „Frei“ angibt. page made young zeigt an, wie oft eine Seite in der LRU-Liste nach vorne verschoben wird. Da der Server den Wert von innodb_old_blocks_time während des Betriebs nicht ändert, ist not young gleich 0. youngs/s und non_youngs/s geben die Anzahl dieser beiden Arten von Vorgängen pro Sekunde an. Die InnoDB-Speicher-Engine unterstützt komprimierte Seiten ab Version 1.0.x, die die ursprüngliche 16-KB-Datenseite auf 1 KB, 2 KB, 4 KB und 8 KB komprimiert. Seiten mit einer Größe von mehr als 16 KB werden von unzip_LRU verwaltet. Zeile 22 im obigen Befehl zeigt die Informationen zu komprimierten und unkomprimierten Seiten. Zu beachten ist, dass die Summe der Werte für freie Puffer und Datenbankseiten nicht unbedingt der Pufferpoolgröße entspricht, da den Seiten im Pufferpool auch Seiten wie adaptive Hash-Indizes und Sperrinformationen zugewiesen sein können und für diese Seiten keine Wartung des LRU-Algorithmus erforderlich ist. Schmutzige SeitenNachdem eine Seite in der LRU-Liste geändert wurde, wird die Seite als „Dirty Page“ bezeichnet, d. h. die Datenseite im Pufferpool stimmt nicht mit den Daten auf der Festplatte überein. Die Daten im Pufferpool sind neuer. Zu diesem Zeitpunkt aktualisiert die Datenbank die Dirty Page über den Checkpoint-Mechanismus zurück auf die Festplatte, und die Seite in der Flush-Liste ist die Dirty Page-Liste. Die Dirty Page ist sowohl in der LRU-Liste als auch in der Flush-Liste vorhanden. Die LRU-Liste wird verwendet, um die Verfügbarkeit von Seiten im Pufferpool zu verwalten, und die Flush-Liste wird verwendet, um die Aktualisierung von Seiten zurück auf die Festplatte zu verwalten. Die beiden beeinflussen sich nicht gegenseitig. Die Flush-Liste kann auch über den InnoDB-Status der Show Engine angezeigt werden. In der 13. Zeile der vorherigen Ergebnisliste ist „Modified DB Pages“ die aktuelle Anzahl schmutziger Seiten, die über die Metadatentabelle INNODB_BUFFER_PAGE_LRU angezeigt werden kann. Oben finden Sie eine ausführliche Erläuterung der Speicherverwaltung der MySQL InnoDB-Speicher-Engine. Weitere Informationen zur InnoDB-Speicherverwaltung finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM! Das könnte Sie auch interessieren:
|
<<: Handschriftliche Implementierung von new in JS
>>: Wichtige Probleme und Lösungen zur Zugriffsgeschwindigkeit auf Webseiten
1. Testumgebung Name Version centos 7.6 Docker 18...
Beim Setzen des Textes im Suchtextfeld springt di...
Vorwort In der Front-End-Entwicklung müssen Sie h...
Problembeschreibung Kürzlich meldete ein Host die...
In letzter Zeit wurde der Server häufig mit Brute...
In diesem Artikel finden Sie das Installations-Tu...
In diesem Artikel wird der spezifische JavaScript...
Downloadadresse der offiziellen MySQL-Website: ht...
Dieser Artikel enthält das ausführliche Tutorial ...
1. Einleitung Vor ein paar Tagen bin ich bei der ...
In diesem Artikel wird der spezifische Code für J...
Methode 1: Verwenden Sie den cmd-Befehl Öffnen Si...
Erneutes Mounten des Datenträgers nach dem Initia...
1. Problembeschreibung: MysqlERROR1698 (28000)-Lö...
MySQL-SQL-Anweisung zum Erstellen einer Tabelle A...