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

Dieser Artikel vermittelt Ihnen relevantes Wissen über MySQL, das hauptsächlich den relevanten Inhalt über die InnoDB-Architektur der Speicher-Engine vorstellt. InnoDB ist die Standard-Engine von MySQL, eine Speicher-Engine, die die Transaktionssicherheit unterstützt es hilft allen.

Empfohlenes Lernen: MySQL-Video-Tutorial

Derzeit fehlen dem MySQL8 viele Funktionen zur Speicheroptimierung. Daher lohnt es sich, ein klares Verständnis der Funktionen der neun derzeit unterstützten Datenbankspeicher-Engines zu erlernen. In diesem Artikel werden die Funktionen, Funktionen und Verwendungsszenarien dieser acht Datenbankspeicher-Engines klar erläutert.

Diese Artikelserie wird in meine Kolumne „SQL-Datenbankoperationen schnell lernen“ aufgenommen, die im Wesentlichen alle Aspekte der Verwendung von SQL für die Abwicklung des Tagesgeschäfts, regelmäßige Abfragedatenbankanalysen und komplexe Vorgänge abdeckt. Von den grundlegenden Schritten zum Erstellen von Datenbanken und Tabellen über die Handhabung verschiedener komplexer Datenbankoperationen bis hin zu professionellen Erklärungen gängiger SQL-Funktionen wurde viel Zeit und Mühe in die Erstellung investiert. Wenn Sie Freunde haben, die sich mit der Datenanalyse befassen müssen Datenentwicklung empfehle ich, die Kolumne zum ersten Mal zu abonnieren. Dieser Blog ist ziemlich lang und verdient sorgfältiges Lesen und Üben. Ich werde die besten Teile auswählen und die Praxis im Detail erklären. Der Blogger wird den Blogbeitrag noch lange pflegen. Wenn Sie Fehler oder Zweifel haben, können Sie diese im Kommentarbereich angeben. Vielen Dank für Ihre Unterstützung.

1. Unterstützte Speicher-Engines

Geben Sie die MySQL-Datenbank ein, um alle von der MySQL-Datenbank unterstützten Speicher-Engines anzuzeigen:

SHOW ENGINES

Derzeit gibt es eine Engine, die Federated nicht unterstützt Ich muss nur wissen, dass der Datenbankspeicher in Ordnung ist.

Zu den gängigen Datenbank-Engines in MySQL gehören MyISAM, InnoDB und Memory. Lassen Sie uns zunächst diese drei Motoren verstehen.

2. InnoDB-Engine

InnoDB ist die Standard-Engine von MySQL, einer Speicher-Engine, die Transaktionssicherheit unterstützt. Daten in MySQL werden auf der physischen Festplatte gespeichert und die eigentliche Datenverarbeitung erfolgt im Speicher. Da die Lese- und Schreibgeschwindigkeit der Festplatte sehr langsam ist, ist die Leistung sehr schlecht, wenn die Festplatte bei jedem Vorgang häufig gelesen und beschrieben wird.

Um die oben genannten Probleme zu lösen, unterteilt InnoDB die Daten in mehrere Seiten und verwendet Seiten als grundlegende Interaktionseinheit zwischen Festplatte und Speicher. Die allgemeine Seitengröße beträgt 16 KB. In diesem Fall wird jeweils mindestens eine Datenseite in den Speicher eingelesen oder jeweils eine Datenseite auf die Festplatte geschrieben. Verbessern Sie die Leistung, indem Sie die Anzahl der Interaktionen zwischen Speicher und Festplatte reduzieren.

Dies ist im Wesentlichen eine typische Cache-Designidee. Im Allgemeinen wird das Cache-Design grundsätzlich aus der Zeitdimension oder der Raumdimension betrachtet:

• Zeitdimension: Wenn ein Datenelement verwendet wird, ist die Wahrscheinlichkeit hoch, dass dies der Fall ist Es wird innerhalb einer bestimmten Zeit wieder verwendet. Es kann davon ausgegangen werden, dass Hotspot-Daten-Caching zur Umsetzung dieser Idee gehört.

• Räumliche Dimension: Wenn ein Datenelement verwendet wird, besteht eine hohe Wahrscheinlichkeit, dass die in der Nähe gespeicherten Daten bald auch verwendet werden. Die Datenseiten und der Seitencache des Betriebssystems von InnoDB verkörpern diese Idee.

Das Folgende ist das offizielle Strukturdiagramm der InnoDB-Engine, das hauptsächlich in zwei Teile unterteilt ist: Speicherstruktur und Festplattenstruktur.

Die Speicherstruktur umfasst hauptsächlich vier Komponenten: Pufferpool, Änderungspuffer, adaptiver Hash-Index und Protokollpuffer.

1.Pufferpool

Der Pufferpool besteht aus Daten, Index, Einfügepuffer, adaptivem Hash-Index, Sperrinformationen und Datenwörterbuch. Pufferpool, als BP bezeichnet. BP basiert auf einer Seite mit einer Standardgröße von 16 KB. Die unterste Ebene von BP verwendet eine verknüpfte Listendatenstruktur zur Verwaltung von Seiten. Wenn InnoDB auf Tabellendatensätze und Indizes zugreift, werden diese auf der Seite zwischengespeichert. Eine spätere Verwendung kann den Festplatten-E/A-Vorgang reduzieren und die Effizienz verbessern.

Pufferpool ist einfach ein Speicherbereich, der die Geschwindigkeit des Speichers nutzt, um die Auswirkungen einer langsamen Festplattengeschwindigkeit auf die Datenbankleistung auszugleichen. Beim Lesen einer Seite in einer Datenbank wird die von der Festplatte gelesene Seite zunächst im Pufferpool gespeichert. Dieser Vorgang wird als „FIX“ der Seite im Pufferpool bezeichnet. Wenn dieselbe Seite das nächste Mal gelesen wird, stellen Sie zunächst fest, ob sich die Seite im Pufferpool befindet. Befindet sie sich im Pufferpool, gilt die Seite als Treffer im Pufferpool. Lesen Sie die Seite direkt durch. Andernfalls wird die Seite auf der Festplatte gelesen. Für den Änderungsvorgang von Seiten in der Datenbank werden die Seiten im Pufferpool zunächst geändert und dann mit einer bestimmten Häufigkeit auf der Festplatte aktualisiert. Hierbei ist zu beachten, dass der Vorgang des Zurückspülens von Seiten aus dem Pufferpool auf die Festplatte nicht jedes Mal ausgelöst wird, wenn die Seite aktualisiert wird, sondern über einen Mechanismus namens Checkpoint auf die Festplatte zurückgespült wird. Auch dies dient dazu, die Gesamtleistung der Datenbank zu verbessern.

Traditioneller LUR-Algorithmus

Der Pufferpool wird über den LRU-Algorithmus (Latest Recent Used, am wenigsten kürzlich verwendet) verwaltet, d. h. die am häufigsten verwendeten Seiten stehen ganz oben in der LRU-Liste und die am wenigsten verwendeten Seiten stehen am Anfang der LRU-Liste. Wenn der Pufferpool am Ende der Liste die neu gelesene Seite nicht speichern kann, wird zuerst die Seite am Ende der LRU-Liste freigegeben:

(1) Die Seite ist bereits vorhanden Der Pufferpool wird also einfach an den Kopf der LRU-Aktion „verschoben“, aber es wird keine Seite entfernt.

(2) Die Seite befindet sich nicht im Pufferpool

Aber der LUR-Algorithmus von InnoDB ist kein traditioneller LUR-Algorithmus.

Hier gibt es zwei Probleme:

(1) Read-Ahead-Fehler;

(2) Pufferpoolverschmutzung;

Read-AheadDisk Lesen und Schreiben: Es handelt sich nicht um das Lesen auf Anforderung, sondern um das Lesen auf Seitenbasis. Es wird jeweils mindestens eine Seite mit Daten (normalerweise 4 KB) gelesen, wenn sich die Daten, die in Zukunft gelesen werden sollen, auf der Seite befinden IO kann weggelassen und die Effizienz verbessert werden. Der Datenzugriff folgt in der Regel dem Prinzip des „konzentrierten Lesens und Schreibens“. Bei der Verwendung einiger Daten besteht eine hohe Wahrscheinlichkeit, dass Daten in der Nähe verwendet werden. Dies ist das sogenannte „Lokalitätsprinzip“, das zeigt, dass ein frühes Laden wirksam ist kann tatsächlich die Festplatten-IO reduzieren.

Read-Ahead-Fehler

Aufgrund des Read-Ahead (Read-Ahead) wird die Seite im Voraus in den Pufferpool gestellt, aber am Ende liest MySQL die Daten nicht von der Seite, was der Fall ist Dies wird als Read-Ahead-Fehler bezeichnet. Um den Fehler beim Vorauslesen zu optimieren, besteht die Idee darin:

(1) Lassen Sie die Seite, die nicht im Voraus gelesen werden konnte, so kurz wie möglich im Pufferpool LRU.

(2) Lassen Sie die Seite die tatsächlich gelesen werden, werden an den Kopf der Pufferpool-LRU verschoben

, um sicherzustellen, dass die tatsächlich gelesenen heißen Daten so lange wie möglich im Pufferpool bleiben.

Die spezifische Methode ist:

(1) Teilen Sie die LRU in zwei Teile:

Neue Generation (neue Unterliste)

Alte Generation (alte Unterliste)

(2) Die neue und die alte Generation werden am Ende verbunden Das heißt: Der Schwanz der neuen Generation ist mit dem Kopf der alten Generation verbunden.

(3) Wenn eine neue Seite (z. B. eine vorgelesene Seite) zum Pufferpool hinzugefügt wird, wird sie nur hinzugefügt zum Kopf der alten Generation:

Wenn die Daten tatsächlich gelesen werden (das Vorlesen ist erfolgreich), werden sie zum Kopf der neuen Generation hinzugefügt

Wenn die Daten nicht gelesen werden, werden sie aus dem Pufferpool entfernt Früher als die „heißen Datenseiten“ der neuen Generation

Neue und alte Studenten Die verbesserte Version von LRU kann das Problem der Pufferpoolverschmutzung immer noch nicht lösen.

2.Log Buffer

Log Buffer wird zum Zwischenspeichern von Redo-Logs verwendet.

InnoDB verfügt über zwei sehr wichtige Protokolle: Undo-Log und Redo-Log

(1) Über das Undo-Log können Sie frühere Versionen von Daten anzeigen, MVCC implementieren oder Transaktionen und andere Funktionen zurücksetzen.

(2) Verwenden Sie das Redo-Log, um die Haltbarkeit der Transaktion sicherzustellen.

Der Redo-Log-Puffer ist ein Speicherbereich, in dem Daten gespeichert werden, die in eine Protokolldatei auf der Festplatte geschrieben werden sollen. Die Größe des Protokollpuffers wird durch die Variable innodb_log_buffer_size definiert und die Standardgröße beträgt 16 MB.

Der Inhalt des Protokollpuffers wird regelmäßig auf die Festplatte geleert. Ein größerer Protokollpuffer ermöglicht die Ausführung großer Transaktionen, ohne dass Redo-Log-Daten vor dem Commit der Transaktion auf die Festplatte geschrieben werden müssen. Wenn daher Transaktionen vorhanden sind, die viele Zeilen aktualisieren, einfügen oder löschen, kann durch Erhöhen der Protokollpuffergröße Festplatten-E/A eingespart werden.

innodb_flush_log_at_trx_commit: Steuert, wie der Inhalt des Protokollpuffers geschrieben und auf die Festplatte geleert wird.

innodb_flush_log_at_timeout: Steuern Sie die Häufigkeit der Protokollaktualisierung.

Sie müssen Transaktionen beobachten, wenn Festplatten-E/A Leistungsprobleme verursacht, z. B. Transaktionen mit vielen BLOB-Einträgen. Der InnoDB-Protokollpuffer wird immer dann auf die Festplatte geleert, wenn er voll ist. Daher kann eine Erhöhung der Puffergröße die E/A reduzieren.

Die Standardanzahl der Protokolldateien beträgt zwei: ib_logfile0 und ib_logfile1.

Das Protokoll hat eine feste Größe, die Standardgröße hängt von der MySQL-Version ab.

3.Adaptiver Hash-Index

Adaptiver Hash-Index Der adaptive Hash-Index ist eine Schlüssel-Wert-Paar-Speicherstruktur, die die Datensätze speichert, in denen sich die Hot Pages befinden. Die InnoDB-Speicher-Engine erstellt automatisch Hash-Indizes für bestimmte Seiten basierend auf der Häufigkeit und dem Muster des Zugriffs.

Das obige Bild zeigt den Unterschied zwischen dem B+-Baumindex und dem adaptiven Hash-Index. Deaktivieren oder aktivieren Sie diese Funktion über den Parameter innodb_adaptive_hash_index, der standardmäßig aktiviert ist.

4.Änderungspuffer: Daten in MySQL sind in zwei Teile unterteilt: Speicher und Festplatte; Hot-Data-Seiten und Indexseiten werden im Pufferpool zwischengespeichert, um Festplattenlesevorgänge zu reduzieren . bedeutet.

Wenn eine Datenseite aktualisiert werden muss, aktualisieren Sie sie direkt, wenn sich die Datenseite im Speicher befindet. Wenn die Datenseite nicht im Speicher ist. Ohne die Datenkonsistenz zu beeinträchtigen, speichert InooDB diese Aktualisierungsvorgänge im Änderungspuffer zwischen, sodass diese Datenseite nicht von der Festplatte gelesen werden muss. Wenn die nächste Abfrage auf diese Datenseite zugreifen muss, lesen Sie die Datenseite in den Speicher und führen Sie dann im Änderungspuffer Vorgänge im Zusammenhang mit dieser Seite aus. Auf diese Weise kann die Korrektheit der Datenlogik sichergestellt werden.

Obwohl der Name Änderungspuffer heißt, handelt es sich tatsächlich um Daten, die beibehalten werden können. Mit anderen Worten: Der Änderungspuffer hat eine Kopie im Speicher und wird auch auf die Festplatte (ibdata) geschrieben.

 Der Vorgang des Zusammenführens der Vorgänge im Änderungspuffer mit der Originaldatenseite und des Erhaltens der neuesten Ergebnisse wird als Zusammenführen bezeichnet. Die folgenden Situationen lösen eine Zusammenführung aus:

• Zugriff auf diese Datenseite;

• Der Hintergrund-Master-Thread wird regelmäßig zusammengeführt;

• Wenn die Datenbank geschlossen ist normalerweise;

• redo Wenn das Protokoll voll ist;

• change buffer bedeutet, dass der Datensatzänderungspuffer verwendet wird, wenn sich eine nicht eindeutige normale Indexseite nicht im Pufferpool befindet Zuerst wird der Datensatz gepuffert, und dann wird der Datensatz geändert, wenn die zukünftigen Daten gelesen werden. Die Technologie im Änderungspuffer wird mit der ursprünglichen Datenseite zusammengeführt. Vor MySQL5.5 hieß es Einfügepuffer (Einfügepuffer) und war nur für das Einfügen optimiert; jetzt ist es auch für Löschen und Aktualisieren gültig und heißt Schreibpuffer (Änderungspuffer).

Empfohlenes Lernen:

MySQL-Video-Tutorial

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der InnoDB-Architektur der MySQL-Speicher-Engine. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!