Der letzte Artikel "Pufferpool (Pufferpool), gründlich verstehen!" "Einführung des Arbeitsprinzips des InnoDB-Pufferpools.
Ein kurzer Überblick: 
(1) Der MySQL-Datenspeicher besteht aus zwei Teilen: Speicher und Festplatte.
(2) Der Speicherpufferpool verwendet Seiten als Einheit, um die heißesten Datenseiten und Indexseiten zwischenzuspeichern. ;
(3) zu den InnoDB-Pufferpool-Management-LRU-Algorithmusvarianten und in der Lage sein, das Problem des "Vorlesefehlers" und der "Pufferpoolverschmutzung" zu lösen;
Voice-over: Details siehe "Pufferpool (Pufferpool), vollständig verstehen! ".
Es besteht kein Zweifel, dass der Pufferpool bei Leseanforderungen die Festplatten-E / A reduzieren und die Leistung verbessern kann. Die Frage ist, was ist mit der Schreibanforderung?
Situation Eins
Angenommen, Sie möchten die Indexseite mit der Seitenzahl 4 ändern, und diese Seite befindet sich zufällig im Pufferpool. 
Wie in der obigen Sequenznummer 1-2 gezeigt:
(1) Ändern Sie direkt die Seite im Pufferpool, eine Speicheroperation;
(2) Schreiben Sie in das Redo-Protokoll eine sequenzielle Schreiboperation für die Festplatte, wobei
diese Effizienz am höchsten ist.
Voice-over: Schreiben Sie in einer Sequenz wie dem Schreiben eines Protokolls, zehntausende Male pro Sekunde, kein Problem.
Wird es Konsistenzprobleme geben?
Nicht wirklich.
(1) Das Lesen trifft die Seiten des Pufferpools;
(2) Die LRU-Daten im Pufferpool werden entfernt und die "schmutzigen Seiten" werden zurück auf die Festplatte geleert.
(3) Die Datenbank ist abnormal abgestürzt und Daten können aus dem Redo-Protokoll wiederhergestellt werden.
Wann werden Seiten im Pufferpool auf die Festplatte geleert?
Durch regelmäßiges Spülen der Festplatte, nicht jedes Mal, können die Festplatten-E / A reduziert und die MySQL-Leistung verbessert werden.
Voice-over: Das Schreiben von Stapeln ist eine gängige Optimierungsmethode.
Situation zwei
Angenommen, Sie möchten die Indexseite mit der Seitenzahl 40 ändern, und diese Seite befindet sich zufällig außerhalb des Pufferpools. 
An diesem Punkt ist es ein wenig problematisch, wie in der obigen Abbildung gezeigt, dass Sie 1-3 benötigen:
(1) Laden Sie zuerst die Indexseite, die 40 sein muss, von der Festplatte in den Pufferpool, eine zufällige Leseoperation von der Festplatte;
(2) Ändern Sie die Seite im Pufferpool, eine Speicheroperation ;
(3) Redo-Protokoll schreiben, eine sequenzielle Schreiboperation;
Wenn der Pufferpool nicht getroffen wird, wird mindestens eine Festplatten-E / A generiert. Gibt es noch Raum für Optimierungen für Geschäftsszenarien, in denen mehr Schreibvorgänge und weniger Lesevorgänge ausgeführt werden?
Dies ist das Problem, das InnoDB berücksichtigt, und es ist der Änderungspuffer, den dieser Artikel behandeln wird.
Voice-over: Aus dem Namen ist leicht ersichtlich, dass die Schreibpufferung ein Mechanismus ist, um die Festplatten-E / A zu reduzieren und die Schreibleistung der Datenbank zu verbessern.
Was ist der Schreibpuffer von InnoDB?
Vor MySQL5.5 wurde es als Einfügepuffer bezeichnet, der nur für das Einfügen optimiert wurde. Jetzt ist es auch zum Löschen und Aktualisieren wirksam, der als Änderungspuffer bezeichnet wird.
Dies ist eine Art Anwendung, wenn sich die nicht eindeutige sekundäre Indexseite nicht im Pufferpool befindet und die Seite geschrieben wird und die Festplattenseite nicht sofort in den Pufferpool geladen wird, sondern nur der Puffer geändert wird (Puffer) Änderungen), wenn die zukünftigen Daten gelesen werden, werden die Daten zusammengeführt und im Pufferpool wiederhergestellt. Der Zweck der Schreibpufferung besteht darin, die Festplatten-E / A für Schreibvorgänge zu reduzieren und die Datenbankleistung zu verbessern.
Voice-over: R hat einen Hund, dieser Satz ist so lang.
InnoDB hat die Schreibpufferoptimierung hinzugefügt. Welche Änderungen werden am obigen "Fall 2" -Prozess vorgenommen?
Angenommen, Sie möchten die Indexseite mit der Seitenzahl 40 ändern, und diese Seite befindet sich zufällig außerhalb des Pufferpools. 
Nach dem Hinzufügen der Schreibpufferoptimierung wird der Prozess wie folgt optimiert:
(1) Zeichnen Sie diese Operation im Schreibpuffer auf, eine Speicheroperation;
(2) Schreiben Sie in das Redo-Protokoll eine sequenzielle Schreiboperation auf der Festplatte, und
ihre Leistung entspricht der der Indexseite im Pufferpool ,ähnlich.
Voice-over: Wie Sie sehen können, wird Seite 40 nicht in den Pufferpool geladen.
Wird es Konsistenzprobleme geben?
Das wird es auch nicht.
(1) Die Datenbank stürzt abnormal ab und Daten können aus dem Redo-Protokoll wiederhergestellt werden.
(2) Der Schreibpuffer ist nicht nur eine Speicherstruktur, er wird auch regelmäßig in den Tabellenbereich des Schreibpuffersystems geleert.
(3) Wenn Daten gelesen werden, gibt es Ein weiterer Prozess ist das Zusammenführen von Daten in den Pufferpool.
Es kann angenommen werden, dass zu einem späteren Zeitpunkt eine Anforderung zum Abfragen der Daten der Indexseite 40 vorliegt. 
Der Prozess ist zu diesem Zeitpunkt wie die Seriennummer 1-3:
(1) Laden Sie die Indexseite, der Pufferpool fehlt, diesmal ist die E / A der Festplatte unvermeidlich;
(2) Lesen Sie verwandte Informationen aus dem Schreibpuffer;
(3) Stellen Sie die Indexseite wieder her und legen Sie sie ein Im Pufferpool LRU;
Voice-Over: Wie Sie sehen, wird Seite 40 beim tatsächlichen Lesen in den Pufferpool geladen.
Es gibt auch eine Auslassung: Warum ist die Schreibpufferoptimierung nur auf nicht eindeutige normale Indexseiten anwendbar?
In InnoDB werden die Ähnlichkeiten und Unterschiede zwischen Clustered-Index und Sekundärindex unter "Grundlegendes zu den Indexunterschieden zwischen MyISAM und InnoDB in 1 Minute" ausführlich beschrieben und nicht erweitert.
Wenn der Index mit einem eindeutigen Attribut festgelegt ist, muss InnoDB während der Änderungsvorgänge eine Eindeutigkeitsprüfung durchführen. Mit anderen Worten, selbst wenn sich die Indexseite nicht im Pufferpool befindet, kann die auf der Festplatte gelesene Seite nicht vermieden werden (andernfalls, wie überprüft wird, ob sie eindeutig ist?). Zu diesem Zeitpunkt sollte die entsprechende Seite direkt in den Pufferpool gestellt und dann geändert werden und sollte dies nicht tun Der ganze Schreibpuffer dieses Yaozi.
Welche anderen Szenarien lösen neben dem Zugriff auf die Datenseite das Löschen der Daten im Puffer aus?
Es gibt verschiedene Situationen, in denen die Daten im Puffer gelöscht werden:
(1) Wenn ein Hintergrundthread vorhanden ist, wird die Datenbank als inaktiv betrachtet.
(2) Wenn der Datenbankpufferpool nicht ausreicht.
(3) Wenn die Datenbank normal heruntergefahren wird.
(4) Wiederherstellen Wenn das Protokoll voll ist,
Voice-Over: Fast kein Redo-Protokoll ist voll, und die gesamte Datenbank befindet sich in einem unbrauchbaren Zustand, der nicht geschrieben werden kann.
Welches Geschäftsszenario eignet sich zur Aktivierung des Schreibpuffermechanismus von InnoDB?
Lassen Sie mich zunächst darüber sprechen, wann es nicht geeignet ist. Wie oben analysiert, wenn:
(1) die Datenbank ein eindeutiger Index ist;
(2) oder nach dem Schreiben von Daten sofort gelesen wird, für
diese beiden Arten von Szenarien, wenn der Schreibvorgang ausgeführt wird ( Nach dem Fortfahren) sollten ursprünglich Seitenlesevorgänge durchgeführt und die entsprechenden Seiten ursprünglich im Pufferpool gespeichert werden. Zu diesem Zeitpunkt wurde das Schreib-Caching zu einer Belastung und zu einer erhöhten Komplexität.
Wann ist es angebracht, den Schreibpuffer zu verwenden, wenn:
(1) der größte Teil der Datenbank ein nicht eindeutiger Index ist;
(2) das Geschäft darin besteht, mehr und weniger gelesen oder nicht unmittelbar nach dem Schreiben zu lesen; der
Schreibpuffer kann verwendet werden, und der ursprüngliche Bedarf für jeden Schreibvorgang Führen Sie Festplatten-E / A-SQL durch und optimieren Sie das regelmäßige Batch-Schreiben auf die Festplatte.
Voice-over: Zum Beispiel das Rechnungsflussgeschäft.
Die obigen Prinzipien entsprechen welchen Parametern in InnoDB?
Es gibt zwei weitere wichtige Parameter. 
Parameter: innodb_change_buffer_max_size
Einführung: Konfigurieren Sie die Größe des Schreibpuffers, der den Anteil des gesamten Pufferpools berücksichtigt. Der Standardwert beträgt 25% und der Maximalwert 50%.
Voice-over: Unternehmen, die mehr schreiben und weniger lesen, müssen diesen Wert erhöhen. Für Unternehmen, die mehr lesen und weniger schreiben, sind 25% tatsächlich mehr.
Parameter: innodb_change_buffering
Einführung: Konfigurieren Sie, welche Schreibvorgänge die Schreibpufferung aktivieren, die auf all / none / inserts / deletes usw. gesetzt werden kann.
Ich hoffe, Sie werden etwas gewinnen, und Ideen sind wichtiger als Schlussfolgerungen. Empfehlungen zu 
technischen Ideen im
Zusammenhang mit dem Road-Sharing des Architekten :
"6 Shell-Tipps, um Skripte professioneller zu machen | 1-Minuten-Serie"
"MyISAM- und InnoDB-Indexdifferenz | 1-Minuten-Serie"
"Pufferpool (Pufferpool), diesmal gründlich verstanden! ! ! "
Lerne zuzuhören, das Wichtigste am Arbeitsplatz!" ! ! 》