Detaillierte Erklärung des Pufferpools in MySQL

Jeder weiß, dass Daten in MySQL auf die Festplatte geschrieben werden müssen. Das Lesen und Schreiben auf die Festplatte ist sehr langsam, insbesondere im Vergleich zum Arbeitsspeicher. Wenn wir jedoch normalerweise SQL ausführen, können sowohl Schreib- als auch Lesevorgänge schnell Ergebnisse liefern und nicht so langsam wie erwartet.

Sie können sagen, dass ich einen Index habe, also ist es mit einem Index natürlich schneller. Aber mein Freund, Indexdateien werden auch auf der Festplatte gespeichert und der Suchvorgang generiert Festplatten-E/A. Wenn mehrere Vorgänge gleichzeitig an einer Datenzeile ausgeführt werden, werden dann nicht viele wiederholte Festplatten-E/A-Vorgänge generiert?

Vielleicht haben Sie darüber nachgedacht: Kann ich die Daten nicht einfach im Speicher ablegen? Es besteht kein Zweifel, dass der Speicher schneller ist als die Festplatte. Das stimmt, aber wie speichert man es? Das ist das Thema, über das wir heute sprechen werden – der Pufferpool.

Liebe Leser, bitte folgen Sie mir~

Abbildung: Mindmap

Erste Schritte mit dem Pufferpool

Wie oben erwähnt, können wir beim Ausführen von SQL zum Bearbeiten einer Zeile Festplattenoperationen nicht immer direkt ausführen. Zumindest gibt es eine Pufferzone, denn wer kann es sonst ertragen, jedes Mal tief ins Nest hineinzugehen.

Hier entsteht der Pufferpool. Einfach ausgedrückt ist es ein Speicherbereich. Einer der Gründe für seine Existenz besteht darin, dass dadurch vermieden werden soll, bei jedem Zugriff auf die Festplatte zugreifen zu müssen. Stattdessen sollen die am häufigsten aufgerufenen Daten in den Cache gestellt werden, um die Zugriffsgeschwindigkeit der Daten zu erhöhen.

Nachdem wir nun seine Funktion kennen, werfen wir einen Blick auf die Position des Pufferpools in der gesamten MySQL-Architektur und verschaffen uns ein Makroverständnis.

Werfen wir einen Blick auf die internen Komponenten. Im Pufferpool gibt es neben Datenseiten und Indexseiten mehrere Typen:

Anwendung des Pufferpools

Nachdem Sie nun über den Pufferpool Bescheid wissen, interessiert Sie wahrscheinlich vor allem die Rolle, die er bei der SQL-Ausführung spielt. Im vorherigen Artikel haben wir kurz den Ausführungsprozess einer SQL-Anweisung erwähnt, sind dabei jedoch nicht auf Probleme im Zusammenhang mit dem Pufferpool eingegangen. In diesem Problem verwenden wir immer noch SQL als Einstiegspunkt.

Beim Ausführen einer SQL-Anweisung wird, sofern es sich um einen Lesevorgang handelt, das Ergebnis zurückgegeben, wenn sich die Datenseite, auf der sich die zu suchenden Daten befinden, im Speicher befindet. Andernfalls wird die entsprechende Datenseite in den Speicher geladen und anschließend das Ergebnis zurückgegeben.

Das Gleiche gilt für Schreibvorgänge. Wenn sich die Datenseite, auf der sich die zu ändernde Zeile befindet, im Speicher befindet, wird nach der Änderung das entsprechende Ergebnis zurückgegeben (natürlich gibt es nachfolgende Vorgänge). Ist dies nicht der Fall, wird die der Zeile entsprechende Datenseite von der Platte in den Speicher gelesen und anschließend geändert.

Okay, kommen wir jetzt zurück zu unserer Ausgangsfrage. Warum ist der Festplattenvorgang langsam, die SQL-Ausführung jedoch nicht? Ich glaube, Sie wissen es wahrscheinlich schon.

Durch die Existenz des Pufferpools wird der durch Festplatten-E/A verursachte Overhead erheblich verringert. Wenn die Datenseite, auf der sich die zu bearbeitende Datenzeile befindet, im Cache vorhanden ist, muss sie nicht von der Festplatte gelesen werden. Auf diese Weise erhalten Sie das Ergebnis schnell nach der Ausführung.

Mechanismus zum Vorlesen des Pufferpools

Wir können erkennen, dass die Ausführungsgeschwindigkeit automatisch zunimmt, wenn kein oder nur ein reduzierter Festplatten-E/A-Vorgang stattfindet. Gibt es also eine bessere Möglichkeit, mit dem unvermeidlichen Festplatten-E/A beim Laden von Datenseiten umzugehen? Da es sich nicht vermeiden lässt, ist die Reduzierung der Anzahl der Festplatten-E/A-Vorgänge immer eine Option, oder?

Dies ist die neue Funktion „Read-Ahead“ in MySQL, über die wir sprechen werden. Auf diese Weise kann Innodb die E/A optimieren, indem mehrere Datenseiten im Voraus im Pufferpool gelesen werden. Da beim Lesen und Schreiben von der Festplatte seitenweise gelesen wird (Sie können dies als Daten mit fester Größe verstehen, z. B. ist eine Datenseite 16 KB groß), wird bei jedem Mal mindestens eine Datenseite gelesen. Wenn sich die beim nächsten Mal zu lesenden Daten auf der Seite befinden, müssen sie nicht erneut von der Festplatte gelesen werden, wodurch die Festplatten-E/A reduziert wird.

Die entsprechende Seitengröße können Sie sich über den folgenden Befehl in der Kommandozeile anzeigen lassen:

Pufferpool-Speicherplatzverwaltung

Sie fragen sich vielleicht: Wenn der Pufferpool gerade so in Mode ist, warum werden dann nicht alle Daten in den Pufferpool gelegt? Diese Geschwindigkeit ist zwar wirklich großartig, aber das Speichern auf der Festplatte ist so langsam wie ein alter Ochse, der einen Karren zieht.

Hey, Bruder, wach auf. Abgesehen von der Flüchtigkeit des Speichers hat auch der Pufferpool eine Größenbeschränkung. Dann sind Sie möglicherweise wieder verwirrt. Da der Pufferpool eine Größenbeschränkung hat, wie verwalte ich die Datenseiten, die ich jedes Mal einlese? Andere Datenseiten haben Platz beansprucht. Wo ist also mein Platz?

Hier werden wir über die Speicherplatzverwaltung des Pufferpools sprechen. Tatsächlich besteht der wichtigste Teil der Verwaltung des Pufferpools darin, wie die Daten im Pool angeordnet und gemäß einer bestimmten Strategie im Pool gelöscht werden, um sicherzustellen, dass die Daten im Pool nicht „überlaufen“, während gleichzeitig sichergestellt wird, dass die häufig verwendeten Daten im Pool verbleiben.

Traditionelle Methode zur LRU-Eliminierung

Der Pufferpool verwaltet Cache-Seiten basierend auf der herkömmlichen LRU-Methode. Sehen wir uns zunächst an, wie er mit LRU verwaltet wird.

LRU, der vollständige Name lautet Least Recently Used, und der chinesische Name lautet „least recently used“. Dies ist anhand des Namens leicht zu verstehen.

Hier gibt es zwei Situationen:

(1) Die Cache-Seite befindet sich bereits im Pufferpool

In diesem Fall wird die entsprechende Cache-Seite an den Anfang der LRU-verknüpften Liste gestellt, ohne dass sie von der Festplatte gelesen oder andere Cache-Seiten gelöscht werden müssen.

Wenn sich die Daten, auf die zugegriffen werden soll, auf Seite 6 befinden, wie in der folgenden Abbildung gezeigt, setzen Sie Seite 6 einfach an den Anfang der verknüpften Liste. In diesem Fall wird keine Cache-Seite gelöscht.

(2) Die Cache-Seite befindet sich nicht im Pufferpool

Die Cache-Seite befindet sich nicht im Puffer. Zu diesem Zeitpunkt muss die entsprechende Datenseite von der Festplatte gelesen, an den Anfang der verknüpften Liste gestellt und die Cache-Seite am Ende gelöscht werden.

Wenn sich die Daten, auf die zugegriffen werden soll, auf Seite 60 befinden und Seite 60 sich nicht im Pufferpool befindet, werden sie, wie in der folgenden Abbildung gezeigt, geladen und an den Anfang der verknüpften Liste gestellt, und die Cacheseite 17 am Ende wird gelöscht.

Sieht die Methode zum Entfernen von Cache-Seiten im Pufferpool nicht einfach aus und ist sie auch zufriedenstellend? Aber lassen Sie uns über ein paar Fragen nachdenken:

Fehler beim Vorlesen

Wir haben oben erwähnt, dass der Vorauslesemechanismus des Pufferpools benachbarte Datenseiten vorab laden kann. Angenommen, es werden zwei nebeneinander liegende Datenseiten 20 und 21 geladen, wobei nur auf die Cache-Seite mit der Seitennummer 20 zugegriffen wird, während auf die andere Cache-Seite nicht zugegriffen wird. Zu diesem Zeitpunkt befinden sich beide Cache-Seiten am Anfang der verknüpften Liste, aber um diese beiden Cache-Seiten zu laden, wird die Cache-Seite am Ende gelöscht und auf die gelöschte Cache-Seite wird häufig zugegriffen. In diesem Fall schlägt das Vorlesen fehl und auf die im Pufferpool vorgeladenen Seiten wird nicht zugegriffen. Ist das nicht unvernünftig?

Pufferpoolverschmutzung
Es gibt eine weitere Situation, in der beim Ausführen einer SQL-Anweisung eine große Datenmenge gescannt oder ein vollständiger Tabellenscan durchgeführt wird. Dabei werden viele Datenseiten in den Pufferpool geladen, wodurch alle vorhandenen Seiten im Pufferpool ersetzt werden. Auch diese Situation ist unvernünftig. Dies stellt eine Pufferpool-Verschmutzung dar und kann zu einem drastischen Leistungsabfall von MySQL führen.

Trennung von heißen und kalten Daten

Es scheint, dass die herkömmliche LRU-Methode die Speicherverwaltungsanforderungen des Pufferpools nicht erfüllen kann. Aus diesem Grund hat Msyql eine Lösung zur Trennung heißer und kalter Daten auf LRU-Basis entwickelt.

Das heißt, die LRU-verknüpfte Liste ist in zwei Teile unterteilt, einen für den Bereich heißer Daten und einen für den Bereich kalter Daten.

Wenn eine Datenseite zum ersten Mal in den Pufferpool geladen wird, wird sie an den Anfang der verknüpften Liste im kalten Datenbereich gestellt. Nach 1 Sekunde (gesteuert durch den Parameter innodb_old_blocks_time) wird auf die Cache-Seite zugegriffen und sie dann an den Anfang der verknüpften Liste im heißen Datenbereich verschoben.

Sie fragen sich vielleicht, warum wir 1 Sekunde warten müssen, bevor wir es in den Hot-Data-Bereich verschieben? Überlegen Sie einmal: Was passiert, wenn auf eine Datenseite direkt nach dem Laden in den Cold-Data-Bereich zugegriffen wird und dann nie wieder darauf zugegriffen wird? Führt dies nicht zu einer Verschwendung von Hot-Data-Bereichen? Wenn innerhalb von 1 Sekunde nicht darauf zugegriffen wird, bedeutet dies, dass in Zukunft möglicherweise nicht mehr häufig darauf zugegriffen wird. Daher besteht keine Notwendigkeit, es in den Hot Buffer zu verschieben. Wenn die Cache-Seiten nicht ausreichen, entfernen Sie sie einfach aus dem Cold-Data-Bereich.

In einem anderen Fall, wenn sich meine Datenseite bereits im Hot Buffer befindet, wird die Cache-Seite in den Kopf der verknüpften Liste eingefügt, solange darauf zugegriffen wird? Es versteht sich von selbst, dass Sie es für unvernünftig halten. Auf die Cache-Seiten im Hot-Data-Bereich wird häufig zugegriffen. Wenn bei jedem Zugriff auf eine Cache-Seite der Linked-List-Header eingefügt wird, herrscht im gesamten Hot-Buffer extrem viel Chaos. Stellen Sie sich diese Szene einfach vor.

Was sollen wir dann tun? In MySQL sind die letzten drei Viertel des Hot-Data-Bereichs so optimiert, dass sie erst nach dem Zugriff an den Anfang der verknüpften Liste verschoben werden, und die Cache-Seiten im ersten Viertel werden nach dem Zugriff nicht verschoben.

Okay, das ist alles zum Pufferpool. In dieser Ausgabe haben wir erläutert, warum der Pufferpool die SQL-Ausführung beschleunigen kann, und auch, wie der Pufferpoolspeicherplatz verwaltet wird. Gerne können Sie im Kommentarbereich darüber diskutieren.

Zusammenfassen

Anwendung des Pufferpools

Der Pufferpool reduziert den durch Festplatten-E/A verursachten Overhead erheblich. Durch das Laden der Datenseiten, auf denen die Datenzeilen bearbeitet werden, in den Pufferpool kann die Ausführungsgeschwindigkeit von SQL verbessert werden.

Mechanismus zum Vorlesen des Pufferpools

Um den Festplatten-E/A-Aufwand zu reduzieren, führt Innodb eine Optimierung durch, indem es im Voraus mehrere Datenseiten im Pufferpool liest. Dies wird als Vorlesen bezeichnet.

Pufferpool-Speicherplatzverwaltung

• Die herkömmliche LRU-Methode für den Pufferpool führt zu zwei Situationen: Fehler beim Vorlesen und Verschmutzung des Pufferpools. Daher ist diese herkömmliche Methode für die Speicherplatzverwaltung des Pufferpools nicht geeignet.
• Basierend auf der Optimierung der LRU-Methode entwickelte Msyql eine Lösung zur Trennung heißer und kalter Daten, indem die LRU-verknüpfte Liste in zwei Teile unterteilt wurde: den Bereich heißer Daten und den Bereich kalter Daten, um die Probleme von Fehlern beim Vorlesen und der Verschmutzung des Pufferpools zu lösen.

Oben finden Sie eine ausführliche Erläuterung des Pufferpools in MySQL. Weitere Informationen zum MySQL-Pufferpool finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!