Ein tiefer Einblick in die MySQL InnoDB-Speicher-Engine

Vorwort

InnoDB gehört in MySQL zur Speicher-Engine-Schicht und ist als Plug-In in die Datenbank integriert. Ab MySQL 5.5.8 wird InnoDB zur Standardspeicher-Engine. Die InnoDB-Speicher-Engine unterstützt Transaktionen und ist hauptsächlich für OLTP-Anwendungen konzipiert. Zu ihren Hauptfunktionen gehören: Unterstützung für Transaktionen, Zeilensperrendesign zur Unterstützung hoher Parallelität, Unterstützung von Fremdschlüsseln, automatische Wiederherstellung nach einem Systemabsturz und Clusterindex zur Organisation der Tabellenstruktur.

Systemarchitektur

Die InnoDB-Speicher-Engine besteht aus drei Teilen: Speicherpool, Hintergrund-Thread und Festplattenspeicher.

Themen

InnoDB verwendet ein Multithread-Modell und im Hintergrund sind mehrere Threads für die Handhabung verschiedener Aufgaben zuständig.

Hauptthread

Der Master-Thread ist der zentrale Hintergrund-Thread, der hauptsächlich für die asynchrone Aktualisierung der Daten im Pufferpool auf der Festplatte verantwortlich ist, um die Datenkonsistenz sicherzustellen. Einschließlich Dirty Page Refresh, Merge Insert Buffer, UNDO Page Recycling usw.

IO-Thread

In der InnoDB-Speicher-Engine wird asynchrone IO (Async IO) häufig verwendet, um Schreib-IO-Anforderungen zu verarbeiten. Die Hauptaufgabe des IO-Threads besteht darin, für den Rückruf dieser IO-Anforderungen verantwortlich zu sein.

Thread bereinigen

Nachdem eine Transaktion festgeschrieben wurde, werden die von ihr verwendeten Undo-Protokolle möglicherweise nicht mehr benötigt. Daher ist ein Bereinigungsthread erforderlich, um die zugewiesenen und verwendeten UNDO-Seiten wiederherzustellen. InnoDB unterstützt mehrere Purge-Threads, die die Wiederherstellung von UNDO-Seiten beschleunigen, die CPU-Auslastung erhöhen und die Leistung der Speicher-Engine verbessern können.

Seitenbereinigungsthread

Die Rolle des Page Cleaner Thread besteht darin, den schmutzigen Seitenaktualisierungsvorgang im Master Thread zu ersetzen. Sein Zweck besteht darin, die Arbeit des ursprünglichen Master Threads und die Blockierung von Benutzerabfrage-Threads zu reduzieren und die Leistung der InnoDB-Speicher-Engine weiter zu verbessern.

Erinnerung

Speicherstruktur der InnoDB-Speicher-Engine

Pufferpool

Die Speicher-Engine InnoDB basiert auf Festplattenspeicher und verwaltet die darin enthaltenen Datensätze seitenweise. Aufgrund der Lücke zwischen CPU-Geschwindigkeit und Festplattengeschwindigkeit verwenden festplattenbasierte Datenbanksysteme jedoch normalerweise Pufferpooldatensätze, um die Gesamtleistung der Datenbank zu verbessern.

Der Pufferpool nutzt tatsächlich die Geschwindigkeit des Speichers, um die Auswirkungen der langsamen Festplattengeschwindigkeit auf die Datenbankleistung auszugleichen. Wenn die Datenbank einen Lesevorgang ausführt, wird die Seite auf der Festplatte zuerst im Pufferpool abgelegt. Wenn dieselbe Seite das nächste Mal gelesen wird, werden die Seitendaten zuerst aus dem Pufferpool abgerufen, der als Cache fungiert.

Bei Datenänderungsvorgängen werden zuerst die Seitendaten im Pufferpool geändert und dann mit einem Mechanismus namens Checkpoint auf die Festplatte aktualisiert.

Die Größe des Pufferpools wirkt sich direkt auf die Gesamtleistung der Datenbank aus. Für die InnoDB-Speicher-Engine wird die Pufferpoolkonfiguration über den Parameter innodb_buffer_pool_size festgelegt. Verwenden Sie den Befehl SHOW VARIABLES LIKE 'innodb_buffer_pool_size', um die Pufferpoolkonfiguration anzuzeigen:

mysql> VARIABLEN WIE 'innodb_buffer_pool_size' ANZEIGEN \G
*************************** 1. Reihe ***************************
Variablenname: innodb_buffer_pool_size
 Wert: 134217728
1 Zeile im Satz (0,01 Sek.)

Zu den im Pufferpool zwischengespeicherten Datenseitentypen gehören: Indexseiten, Rückgängig-Seiten, Einfügepuffer, adaptive Hash-Indizes, InnoDB-Sperrinformationen, Datenwörterbuchinformationen usw. Indexseiten und Datenseiten belegen einen großen Teil des Pufferpools.

Redo-Log-Puffer

Wenn die Seitendaten im Pufferpool neuer sind als die Festplatte, müssen die neuen Daten auf die Festplatte geschrieben werden. InnoDB verwendet die Write Ahead Log-Strategie zum Aktualisieren von Daten. Das heißt, wenn eine Transaktion festgeschrieben wird, wird sie zuerst in den Redo-Log-Puffer geschrieben. Der Redo-Log-Puffer wird in einer bestimmten Häufigkeit in die Reset-Log-Datei aktualisiert, und dann werden die schmutzigen Seiten gemäß dem Checkpoint-Mechanismus auf die Festplatte aktualisiert.

Der Redo-Log-Puffer muss nicht sehr groß eingestellt werden. Normalerweise reichen 8 MB für die meisten Anwendungsszenarien aus. Das Redo-Protokoll unterstützt die folgenden drei Situationen, um eine Aktualisierung auszulösen:

• Der Master-Thread leert den Redo-Log-Puffer jede Sekunde in die Redo-Log-Datei.
• Leeren des Redo-Log-Puffers in die Redo-Log-Datei bei jedem Commit einer Transaktion
• Wenn der verbleibende Speicherplatz im Redo-Log-Pufferpool weniger als 1/2 beträgt, wird der Redo-Log-Puffer in die Redo-Log-Datei geleert.

Zusätzlicher Speicherpool

In der InnoDB-Speicher-Engine wird der Speicher über eine Methode namens Speicherheap verwaltet. Bei der Speicherzuweisung für einige Datenstrukturen selbst muss auf einen zusätzlichen Speicherpool zurückgegriffen werden. Wenn der Speicher in diesem Bereich nicht ausreicht, wird auf den Pufferpool zurückgegriffen.

Sperren

Die von InnoDB unterstützten Sperren sind:

• Gemeinsam genutzte Sperren und exklusive Sperren
• Absichtssperre
• Datensatzsperre
• Lückensperre
• Auto-Inkrement-Sperre

Gemeinsam genutzte Sperren und exklusive Sperren

Die InnoDB-Engine implementiert zwei Standardsperren auf Zeilenebene: gemeinsame Sperren (S) und exklusive Sperren (X). Eine gemeinsam genutzte Sperre ermöglicht einer Transaktion, die die Sperre hält, das Lesen einer Datenzeile, während eine exklusive Sperre einer Transaktion das Schreiben einer Datensatzzeile ermöglicht.

Wenn eine Transaktion eine gemeinsame Sperre hält, können andere Transaktionen dennoch eine gemeinsame Sperre für diese Datensatzzeile erhalten, aber keine exklusive Sperre für diese Datensatzzeile. Wenn eine Transaktion eine exklusive Sperre für eine Zeile erhält, können andere Transaktionen keine gemeinsamen Sperren und keine exklusiven Sperren mehr für diese Zeile erhalten.

Absichtssperre

In InnoDB ist die Intention-Sperre eine Sperre auf Tabellenebene, die in eine gemeinsame Sperre und eine exklusive Sperre unterteilt ist:

• Absichtliche gemeinsame Sperre: um eine gemeinsame Sperre für eine Zeile zu erhalten
• Absicht exklusive Sperre: Um eine exklusive Sperre für eine Zeile zu erhalten

Eine Transaktion muss zuerst eine beabsichtigte gemeinsame/exklusive Sperre erwerben, bevor sie eine gemeinsame/exklusive Sperre erwerben kann. Die beabsichtigte Sperre blockiert keine anderen Vorgänge in der Tabelle. Sie teilt anderen Transaktionen lediglich mit, dass sie eine gemeinsame oder exklusive Sperre für eine Zeile erwerben wird.

Datensatzsperre

Record Locks ist eine Sperre für einen Index. Sie sperrt den Index eines Datensatzes und nicht den Datensatz selbst. Wenn die aktuelle Tabelle keinen Index hat, erstellt InnoDB einen versteckten Clusterindex dafür und Record Locks sperrt diesen versteckten Clusterindex.

Lückensperre

Lückensperren wirken wie Datensatzsperren auch auf Indizes. Der Unterschied besteht darin, dass Datensatzsperren nur auf einen Indexdatensatz wirken, während Lückensperren einen Indexbereich sperren können. Die einzige Funktion von Gap Locks in InnoDB besteht darin, das Einfügen von Daten durch andere Transaktionen zu verhindern und so Phantomlesevorgänge zu vermeiden.

Auto-Inkrement-Sperre

Die Auto-Increment-Sperre ist eine spezielle Sperre auf Tabellenebene, die nur bei Einfügevorgängen funktioniert, die Auto-Increment-Spalten enthalten. Wenn eine Transaktion ein Datenelement einfügt, muss jede andere Transaktion warten, bis die gesamte Transaktion den Einfügevorgang abgeschlossen hat, und dann die Sperre erwerben, um den Einfügevorgang auszuführen.

Transaktionen

SÄURE

Transaktionen sind das wichtigste Merkmal von OLTP-Datenbanken. Wenn wir über Transaktionen sprechen, müssen wir die vier grundlegenden Merkmale von ACID erwähnen:

• Atomarität: Die kleinste Arbeitseinheit in einer Transaktion, entweder alle erfolgreich oder alle fehlgeschlagen
• Konsistenz: Die Integrität der Datenbank wird nach dem Start und Ende einer Transaktion nicht beeinträchtigt.
• Isolation: Verschiedene Transaktionen beeinflussen sich nicht gegenseitig. Die vier Isolationsstufen sind RU (Read Uncommitted), RC (Read Committed), RR (Repeatable Read) und SERIALIZABLE (Serializable).
• Dauerhaftigkeit: Nach der Durchführung einer Transaktion sind die Datenänderungen dauerhaft und gehen auch bei einem Systemausfall nicht verloren.

Die Atomizität, Persistenz und Konsistenz von InnoDB werden hauptsächlich durch die Mechanismen Redo Log, Undo Log und Force Log at Commit erreicht. Redo Log wird verwendet, um Daten im Falle eines Absturzes wiederherzustellen, und Undo Log wird verwendet, um die Auswirkungen einer Transaktion rückgängig zu machen. Es kann auch zur Kontrolle mehrerer Versionen verwendet werden. Der Mechanismus „Force Log at Commit“ stellt sicher, dass die Redo-Protokolle nach dem Commit der Transaktion erhalten bleiben. Die Isolierung wird durch Sperren und MVCC gewährleistet.

Isolationsstufe

In MySQL gibt es vier Transaktionsisolationsebenen:

• Nicht festgeschrieben lesen
• Lesen Sie Commitment
• Wiederholbares Lesen
• Serialisierbar

Bevor wir die vier Isolationsebenen verstehen, müssen wir drei weitere Begriffe verstehen:

• Schmutzige Lektüre

Transaktion A liest Daten, die Transaktion B noch nicht festgeschrieben hat, aber Transaktion B wird aus irgendeinem Grund zurückgesetzt. Auf diese Weise sind die von Transaktion A gelesenen Daten nicht verfügbar, was zu einigen abnormalen Ergebnissen führt.

• Nicht wiederholbares Lesen

Dabei werden im Transaktionszyklus A bestimmte Daten mehrfach abgefragt und gleichzeitig in der Transaktion B aktualisiert oder gelöscht. Dann können die Ergebnisse jeder Abfrage der Transaktion A unterschiedlich sein.

• Phantom lesen

Das Ergebnis des Phantomlesens ist tatsächlich dasselbe wie das des nicht wiederholbaren Lesens. Der Unterschied besteht darin, dass beim nicht wiederholbaren Lesen hauptsächlich Bearbeitungs- (Aktualisierungs-) und Löschvorgänge (Löschen) für andere Transaktionen ausgeführt werden. Das Phantomlesen dient hauptsächlich Einfügevorgängen. Das heißt, innerhalb des Lebenszyklus einer Transaktion werden die neu eingefügten Daten einer anderen Transaktion abgefragt.

Nicht festgeschrieben lesen

Nicht festgeschriebenes Lesen. In diesem Fall kann eine Transaktion a die nicht festgeschriebenen Daten einer anderen Transaktion b sehen. Wenn Transaktion b zu diesem Zeitpunkt zurückgesetzt wird, erhält Transaktion a schmutzige Daten, was die Bedeutung von „schmutzigem Lesen“ ist.

Diese Isolationsebene wird in MySQL InnoDB im Allgemeinen nicht empfohlen.

Lesen Sie Commitment

Lesen festgeschrieben: Alle von einer Transaktion vom Beginn bis zum Festschreiben vorgenommenen Änderungen sind für andere Transaktionen nicht sichtbar. Das Dirty-Read-Problem ist gelöst, aber Phantom-Reads sind immer noch vorhanden.

Wiederholbares Lesen

Wiederholbares Lesen: Diese Ebene stellt sicher, dass die Ergebnisse des mehrmaligen Lesens desselben Datensatzes in derselben Transaktion konsistent sind. Sie löst sowohl das Phantomlese- als auch das nicht wiederholbare Leseproblem in der InnoDB-Speicher-Engine.

Die InnoDB-Engine löst das Phantomleseproblem durch die Verwendung von Next-Key Lock. Next-Key Lock ist eine Kombination aus Zeilensperre und Lückensperre. Wenn InnoDB Indexdatensätze scannt, fügt es zuerst den Indexdatensätzen eine Zeilensperre (Record Lock) hinzu und fügt dann den Lücken auf beiden Seiten der Indexdatensätze eine Lückensperre (Gap Lock) hinzu. Nach dem Hinzufügen der Lückensperre können andere Transaktionen keine Datensätze in dieser Lücke ändern oder einfügen.

Serialisierbar

Serializable ist die höchste Isolationsebene. Sie vermeidet das Problem von Phantom-Lesevorgängen, indem sie die serielle Ausführung von Transaktionen erzwingt. Allerdings sperrt Serializable jede gelesene Datenzeile, was zu einer großen Anzahl von Timeouts und Sperrkonflikten führen kann. Dadurch sinkt die Parallelität stark. Es wird auch nicht empfohlen, es in MySQL InnoDB zu verwenden.

Offene Transaktion

• BEGINNEN, ARBEIT BEGINNEN, TRANSAKTION STARTEN

Durch die Ausführung des BEGIN-Befehls wird nicht tatsächlich eine neue Transaktion auf Engine-Ebene gestartet, sondern es wird lediglich eine Markierung für den aktuellen Thread gesetzt, um anzuzeigen, dass es sich um eine explizit gestartete Transaktion handelt.

• START TRANSAKTION NUR LESEN

Wenn eine schreibgeschützte Transaktion aktiviert ist und MySQL Server SQL für Datenänderungen empfängt, lehnt es die Änderung der Daten direkt ab und gibt einen Fehler zurück. Dieser Fehler gelangt nicht in die Engine-Ebene.

• START TRANSAKTION LESEN SCHREIBEN

Ermöglicht dem Superuser, Lese-/Schreibtransaktionen zu starten, wenn der schreibgeschützte Status des aktuellen Threads „true“ ist.

• STARTEN SIE DIE TRANSAKTION MIT EINEM KONSEQUENTEN SNAPSHOT

Durch das Öffnen einer Transaktion gelangt man in die Engine-Ebene und öffnet eine Lese-Ansicht. Dieser Vorgang ist nur auf der RR-Isolationsebene gültig. Andernfalls wird ein Fehler gemeldet.

Undo-Protokoll

Wenn Daten geändert werden, wird das entsprechende Undo-Protokoll aufgezeichnet. Wenn die Transaktion fehlschlägt oder zurückgesetzt wird, kann sie mithilfe des aufgezeichneten Undo-Protokolls zurückgesetzt werden. Das Undo-Log ist ein logisches Protokoll, das das Datenabbild vor der Änderung aufzeichnet. Wenn bei der Änderung gleichzeitig die aktuellen Daten gelesen werden müssen, kann anhand der Versionsinformationen die vorherige Version der in der Zeile aufgezeichneten Daten analysiert werden. Darüber hinaus generiert das Undo-Protokoll auch ein Redo-Protokoll, da das Undo-Protokoll ebenfalls dauerhaft geschützt werden muss.

Transaktions-Commit

1. Verwenden Sie den globalen Transaktions-ID-Generator, um die Transaktionsnummer zu generieren, und fügen Sie den Transaktionszeiger (trx_t) der aktuellen Verbindung zur globalen Liste der festgeschriebenen Transaktionen (trx_serial_list) hinzu.
2. Rückgängig markieren. Wenn diese Transaktion nur eine UndoPage verwendet und die Nutzung weniger als 3/4 der Seite beträgt, markieren Sie diese Seite als TRX_UNDO_CACHED. Wenn die Anforderung nicht erfüllt ist und es sich um ein Einfüge-Rückgängigmachen handelt, markieren Sie es als TRX_UNDO_TO_FREE. Andernfalls, wenn das Rückgängigmachen ein Aktualisierungs-Rückgängigmachen ist, markieren Sie es als TRX_UNDO_TO_PURGE. Als TRX_UNDO_CACHED markiertes Rückgängigmachen wird von der Engine erneut ausgeführt.
3. Fügen Sie das Update-Undo in die Verlaufsliste des Undo-Segments ein und erhöhen Sie rseg_history_len (global). Aktualisieren Sie gleichzeitig TRX_UNDO_TRX_NO auf der Seite und setzen Sie delete_mark zurück, wenn die Daten gelöscht werden.
4. Löschen Sie Undate Undo aus der Update-Undo-Liste. Wenn es als TRX_UNDO_CACHED markiert ist, fügen Sie es der Update-Undo-Cached-Warteschlange hinzu.
5. mtr_commit (Rückgängig-/Wiederherstellen-Protokoll wird in den öffentlichen Puffer geschrieben), bisher wird die Transaktion auf Dateiebene festgeschrieben. Selbst wenn das System abstürzt, kann die Transaktion zu diesem Zeitpunkt nach einem Neustart noch ausgeführt werden. Als nächstes muss der Speicherdatenstatus aktualisiert werden (trx_commit_in_memory).
6. Nur-Lese-Transaktionen müssen nur die Readview aus der globalen Readview-Liste entfernen und die Informationen in der trx_t-Struktur zurücksetzen. Die Lese-/Schreibtransaktion muss zuerst den Transaktionsstatus auf TRX_STATE_COMMITTED_IN_MEMORY setzen, alle Zeilensperren freigeben und trx_t aus rw_trx_list entfernen und readview aus der globalen Readview-Liste entfernen. Wenn ein Einfüge-Rückgängig gemacht wurde, entfernen Sie es hier. Wenn ein Aktualisierungs-Rückgängig gemacht wurde, aktivieren Sie den Bereinigungs-Thread, um den Datenmüll zu beseitigen. Setzen Sie abschließend die Informationen in trx_t für die nächste Transaktion zurück.

Rollback

• Handelt es sich um eine schreibgeschützte Transaktion, wird direkt zurückgegeben
• Bestimmen Sie, ob die gesamte Transaktion oder ein Teil der Transaktion zurückgesetzt werden soll. Wenn es sich um eine Teiltransaktion handelt, zeichnen Sie auf, wie viele Undo-Protokolle aufbewahrt werden müssen, und führen Sie für alle überzähligen Protokolle ein Rollback durch.
• Suchen Sie das letzte Undo aus Update-Undo und Insert-Undo und rollen Sie von diesem Undo zurück
• Wenn die Aktualisierung rückgängig gemacht wird, werden die als gelöscht markierten Datensätze entfernt und die aktualisierten Daten auf die älteste Version zurückgesetzt. Wenn das Einfügen rückgängig gemacht wird, löschen Sie den Clusterindex und den Sekundärindex direkt
• Wenn alle Undo-Aktionen rückgängig gemacht oder auf die angegebene Rückgängig-Maßnahme zurückgesetzt wurden, stoppen und löschen Sie das Undo-Protokoll.

Index

Die InnoDB-Engine verwendet einen B+-Baum als Indexstruktur. Der Datenbereich des Blattknotens des Primärschlüsselindex speichert die vollständigen Felddaten, und der Blattknoten des Nicht-Primärschlüsselindex speichert die Wertdaten, die auf den Primärschlüssel verweisen.

Die obige Abbildung ist ein schematisches Diagramm des InnoDB-Primärindex (der auch eine Datendatei ist). Sie können sehen, dass der Blattknoten vollständige Datensätze enthält. Dieser Indextyp wird als gruppierter Index bezeichnet. Da die Datendateien von InnoDB selbst nach Primärschlüsseln gruppiert sind, erfordert InnoDB, dass Tabellen Primärschlüssel haben müssen. Wenn nicht explizit angegeben, wählt das MySQL-System automatisch eine Spalte aus, die Datensätze eindeutig als Primärschlüssel identifizieren kann. Wenn eine solche Spalte nicht vorhanden ist, generiert MySQL automatisch ein implizites Feld für die InnoDB-Tabelle als Primärschlüssel. Dieses Feld ist 6 Byte lang und vom Typ „Long Integer“.

Das sekundäre Indexdatenfeld von InnoDB speichert anstelle der Adresse den Wert des entsprechenden Primärschlüssels des Datensatzes. Mit anderen Worten: Alle sekundären Indizes von InnoDB verweisen auf den Primärschlüssel als Datenfeld. Durch die Implementierung eines gruppierten Index ist die Suche nach Primärschlüsseln sehr effizient, für die Suche im Hilfsindex sind jedoch zwei Indexsuchen erforderlich: Durchsuchen Sie zuerst den Hilfsindex, um den Primärschlüssel zu erhalten, und verwenden Sie dann den Primärschlüssel, um den Datensatz aus dem Primärindex abzurufen.

Abschluss

Dieser Artikel stellt nur einen kleinen Teil der zahlreichen Funktionen von MySQL InnoDB vor. Interessierte Studierende können „MySQL Technology Insider: InnoDB Storage Engine“ lesen, um mehr über verwandte Themen zu erfahren.

Nun, das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.