Detaillierte Erläuterung der Speicherverwaltung der MySQL InnoDB-Speicher-Engine

Detaillierte Erläuterung der Speicherverwaltung der MySQL InnoDB-Speicher-Engine

Speicherverwaltung der Speicher-Engine

In 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 Seiten

Nachdem 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:
  • Analyse basierend auf der MySQL-Architektur
  • Detaillierte Analyse basierend auf der MySQL-Architektur
  • Detaillierte Erklärung der Speicher-Engine in MySQL
  • Kenntnisse über die MySQL Memory-Speicher-Engine
  • Unterschiede und Vergleiche von Speicher-Engines in MySQL
  • MySQL Series 7 MySQL-Speicher-Engine
  • Detaillierte Erläuterung verschiedener Sperren in der InnoDB-Speicher-Engine in MySQL
  • Detaillierte Erklärung nicht gruppierter Indizes in der MyISAM-Speicher-Engine von MySQL
  • MySQL-Speicher-Engines InnoDB und MyISAM
  • Einführung in die MySQL-Architektur und Speicher-Engine

<<:  Handschriftliche Implementierung von new in JS

>>:  Wichtige Probleme und Lösungen zur Zugriffsgeschwindigkeit auf Webseiten

Artikel empfehlen

Online- und Offlineinstallation von Docker und allgemeine Befehlsvorgänge

1. Testumgebung Name Version centos 7.6 Docker 18...

Mit JS in zehn Minuten die Existenz von Elementen in einem Array bestimmen

Vorwort In der Front-End-Entwicklung müssen Sie h...

So behandeln Sie den vom Linux-System gemeldeten Fehler tcp_mark_head_lost

Problembeschreibung Kürzlich meldete ein Host die...

Sicherheitskonfigurationsstrategie für CentOS-Server

In letzter Zeit wurde der Server häufig mit Brute...

Tutorial zur Installation der Dekomprimierungsversion von MySQL 8.0.12

In diesem Artikel finden Sie das Installations-Tu...

JavaScript zum Erzielen eines Produktlupeneffekts

In diesem Artikel wird der spezifische JavaScript...

So installieren Sie MySQL Community Server 5.6.39

Dieser Artikel enthält das ausführliche Tutorial ...

Lösen Sie das Problem, dass await in forEach nicht funktioniert

1. Einleitung Vor ein paar Tagen bin ich bei der ...

JavaScript zur Implementierung der Schaltfläche „Zurück nach oben“

In diesem Artikel wird der spezifische Code für J...

Zwei Möglichkeiten zum Öffnen und Schließen des MySQL-Dienstes

Methode 1: Verwenden Sie den cmd-Befehl Öffnen Si...

Lösung für MySql-Fehler 1698 (28000)

1. Problembeschreibung: MysqlERROR1698 (28000)-Lö...