Detaillierte Analyse von MySQL-Datenbanktransaktionen und -Sperren

1. Grundlegende Konzepte

Eine Transaktion ist eine Reihe von Vorgängen, die die ACID-Eigenschaften erfüllen. Transaktionen können mit Commit festgeschrieben und mit Rollback rückgängig gemacht werden. Es gibt Zwischenzustände und konsistente Zustände (das sind auch die Zustände, die tatsächlich in der Datenbanktabelle vorhanden sind).

SÄURE

Atomarität : Eine Transaktion wird als unteilbare Kleinsteinheit betrachtet und alle Vorgänge einer Transaktion werden entweder erfolgreich ausgeführt oder es schlagen alle fehl und werden zurückgesetzt. Ein Rollback kann mithilfe eines Undo-Logs erfolgen, das die von der Transaktion durchgeführten Änderungsvorgänge aufzeichnet. Beim Rollback können diese Änderungsvorgänge rückgängig gemacht werden.

UndoLog: Um die Atomarität von Transaktionen sicherzustellen, sichern Sie die Daten vor der Verarbeitung zunächst im Undo-Protokoll und ändern Sie sie dann. Wenn ein Fehler auftritt oder der Benutzer eine ROLLBACK-Anweisung ausführt, kann das System die Sicherung im Undo-Protokoll verwenden, um die Daten in den Zustand vor Beginn der Transaktion wiederherzustellen. Anders als beim Redo-Log gibt es keine separate Undo-Logdatei auf der Festplatte. Sie wird in einem speziellen Segment innerhalb der Datenbank gespeichert, das als Undo-Segment bezeichnet wird. Das Undo-Segment befindet sich im gemeinsam genutzten Tablespace. Innodb implementiert drei versteckte Felder für jede Datensatzzeile: 6-Byte-Transaktions-ID (DB_TRX_ID) 7-Byte-Rollback-Zeiger (DB_ROLL_PTR) Versteckte ID

Konsistenz: Die Datenbank behält vor und nach der Ausführung der Transaktion einen konsistenten Zustand bei. Im konsistenten Zustand haben alle Transaktionen dieselben Leseergebnisse für dieselben Daten.

Isolation : Von einer Transaktion vorgenommene Änderungen sind für andere Transaktionen erst sichtbar, wenn sie endgültig festgeschrieben sind.

Dauerhaftigkeit : Sobald eine Transaktion ausgeführt wurde, werden die vorgenommenen Änderungen dauerhaft in der Datenbank gespeichert. Selbst wenn das System abstürzt, gehen die Ergebnisse der Transaktionsausführung nicht verloren. Wenn ein Systemabsturz auftritt, kann RedoLog zur Wiederherstellung verwendet werden, um so Persistenz zu erreichen. Im Gegensatz zu undoLog, das logische Änderungen an Daten aufzeichnet, zeichnet redoLog eine Zusammenfassung der physischen Änderungen an Datenseiten auf:
1. Nur wenn die Konsistenz gewährleistet ist, kann das Ausführungsergebnis der Transaktion korrekt sein.
2. Wenn keine Parallelität vorliegt, werden Transaktionen seriell ausgeführt und die Isolation kann erreicht werden. Solange zu diesem Zeitpunkt die Atomarität eingehalten werden kann, kann auch die Konsistenz gewährleistet werden.
3. Bei Parallelität werden mehrere Transaktionen parallel ausgeführt. Transaktionen müssen nicht nur Atomarität, sondern auch Isolation erfüllen, um Konsistenz zu gewährleisten.
4. Transaktionen müssen persistent sein, um Systemabstürze zu verkraften

3.AutoCommit

MySQL verwendet standardmäßig den Auto-Commit-Modus , d. h. wenn Sie nicht explizit die Anweisung „Start Transaction“ zum Starten einer Transaktion verwenden, wird jeder Vorgang als Transaktion behandelt und automatisch festgeschrieben.

4. Transaktionsisolationsebene

Nicht festgeschriebenes Lesen: Änderungen in einer Transaktion sind für andere Transaktionen sichtbar, auch wenn sie nicht festgeschrieben sind.

Festgeschrieben lesen: Eine Transaktion kann nur Änderungen lesen, die von festgeschriebenen Transaktionen vorgenommen wurden. Mit anderen Worten: Änderungen, die von einer Transaktion vorgenommen wurden, sind für andere Transaktionen erst sichtbar, wenn sie festgeschrieben wurden.

Wiederholbares Lesen: stellt sicher, dass die Ergebnisse des mehrmaligen Lesens derselben Daten in derselben Transaktion gleich sind. Serialisierbar: erzwingt die serielle Ausführung von Transaktionen, sodass mehrere Transaktionen einander nicht beeinträchtigen und es keine gleichzeitigen Konsistenzprobleme gibt. Diese Isolationsebene erfordert die Implementierung einer Sperre, da der Sperrmechanismus verwendet wird, um sicherzustellen, dass nur eine Transaktion gleichzeitig ausgeführt wird, d. h. um sicherzustellen, dass Transaktionen seriell ausgeführt werden.

5. Probleme mit der Parallelitätskonsistenz

Hintergrund

In einer gleichzeitigen Umgebung lässt sich die Isolierung von Transaktionen nur schwer gewährleisten, sodass viele gleichzeitige Konsistenzprobleme auftreten.

Hauptszenen

Verlorene Änderung: Eine verlorene Änderung bedeutet, dass eine Aktualisierungsoperation einer Transaktion durch eine Aktualisierungsoperation einer anderen Transaktion ersetzt wird. Beispielsweise ändern die Transaktionen T1 und T2 beide ein Datenelement. T1 ändert und überträgt die Daten zuerst, und T2 ändert die Daten später. Die Änderung von T2 überschreibt die Änderung von T1.
Geschäftsszenarien: Benutzer können Adressen ändern, indem sie Adressinformationen ändern, eine Standardadresse festlegen oder eine Adresse löschen. In diesen drei Szenarien wird dieselbe Update-Anweisung aufgerufen. Die Schnittstelle, die Benutzern zum Aktualisieren von Adressen bereitgestellt wird, muss Benutzern das Festlegen von Standardadressen ermöglichen. Die Schnittstellen zum Aktualisieren von Adressinformationen und zum Festlegen von Standardadressen können nicht separat bereitgestellt werden. Wenn sie separat bereitgestellt werden, ruft der Serviceaufruf der oberen Ebene tatsächlich zwei Aktualisierungsschnittstellen gleichzeitig auf, was leicht zum Verlust von Änderungen führen kann.

Lesen von fehlerhaften Daten: Das Lesen fehlerhafter Daten bedeutet, dass die aktuelle Transaktion bei verschiedenen Transaktionen Daten lesen kann, die nicht von anderen Transaktionen festgeschrieben wurden. Beispielsweise ändert T1 Daten, schreibt sie aber nicht fest, und T2 liest die Daten anschließend. Wenn T1 diese Änderung rückgängig macht, sind die von T2 gelesenen Daten fehlerhafte Daten.

Nicht wiederholbares Lesen: Nicht wiederholbares Lesen bezeichnet das mehrmalige Lesen desselben Datensatzes innerhalb einer Transaktion. Bevor die Transaktion endet, greift eine weitere Transaktion ebenfalls auf denselben Datensatz zu und nimmt Änderungen vor. Aufgrund der Änderungen der zweiten Transaktion können die von der ersten Transaktion zweimal gelesenen Daten inkonsistent sein. Beispiel: T2 liest Daten und T1 ändert die Daten. Wenn T2 die Daten erneut liest, unterscheidet sich das Ergebnis dieses Lesens vom Ergebnis des ersten Lesens.

Phantomlesen: Beim Phantomlesen handelt es sich im Wesentlichen um ein nicht wiederholbares Lesen. T1 liest einen Datenbereich, T2 fügt neue Daten in diesen Bereich ein und T1 liest die Daten in diesem Bereich erneut. Das Ergebnis dieses Lesevorgangs unterscheidet sich vom Ergebnis des ersten Lesevorgangs.

Zusammenfassung:
Der Hauptgrund für Inkonsistenzprobleme bei gleichzeitigen Vorgängen ist die Zerstörung der Transaktionsisolation. Die Lösung besteht darin, die Isolation durch Parallelitätskontrolle sicherzustellen. Die Parallelitätskontrolle kann durch Blockieren erreicht werden, der Blockierungsvorgang erfordert jedoch die Kontrolle durch den Benutzer, was ziemlich kompliziert ist. Datenbankverwaltungssysteme bieten Transaktionsisolationsebenen, sodass Benutzer gleichzeitig auftretende Konsistenzprobleme einfacher lösen können.

6. Sperren

Sperrgranularität:

Sperre auf Zeilenebene: Nur der Teil der Daten oder die Zeile, der geändert werden muss, wird gesperrt, nicht alle Ressourcen. Die Möglichkeit von Sperrkonflikten ist gering und die Systemparallelität hoch.

Sperre auf Tabellenebene: Die gesamte Tabelle ist gesperrt. Die Menge der gesperrten Daten ist zu groß, was die Wahrscheinlichkeit von Sperrkonflikten erheblich erhöht und zu einem starken Rückgang der Systemparallelitätsleistung führt.

Hinweis: Sperren verbrauchen Ressourcen. Alle Sperrvorgänge (einschließlich Sperrenerlangen, Sperrenaufheben und Sperrstatusüberprüfung) erhöhen den Systemaufwand. Daher gilt: Je kleiner die Sperrgranularität, desto größer der Systemaufwand. Bei der Wahl der Sperrgranularität müssen Sie einen Kompromiss zwischen Sperraufwand und Parallelität eingehen.

Sperrtyp

Lese-/Schreibsperre

Mutex-Lock, abgekürzt X-Lock, wird auch Schreibsperre genannt.
Eine Transaktion fügt dem Datenobjekt A eine X-Sperre hinzu und kann A lesen und aktualisieren. Während der Sperrfrist können andere Transaktionen keine Sperren zu A hinzufügen.

Shared Lock, abgekürzt S-Lock, wird auch Lese-Lock genannt.
Eine Transaktion fügt dem Datenobjekt A eine S-Sperre hinzu. A kann gelesen, aber nicht aktualisiert werden. Während der Sperrfrist können andere Transaktionen eine S-Sperre zu A hinzufügen, aber keine X-Sperre.

Absichtssperre

Hauptsächlich Tabellensperre, aber keine echte Sperre

Wenn bei vorhandenen Sperren auf Zeilen- und Tabellenebene die Transaktion T eine X-Sperre zu Tabelle A hinzufügen möchte, muss sie zunächst feststellen, ob andere Transaktionen die Tabelle A oder eine beliebige Zeile in Tabelle A gesperrt haben. Anschließend muss sie jede Zeile der Tabelle A prüfen, was sehr zeitaufwändig ist.
Absichtssperren führen IX/IS zusätzlich zu den ursprünglichen X/S-Sperren ein. IX/IS sind beides Tabellensperren, die verwendet werden, um anzuzeigen, dass eine Transaktion einer bestimmten Datenzeile in der Tabelle eine X-Sperre oder eine S-Sperre hinzufügen möchte.
Es gibt zwei Bestimmungen:
Bevor eine Transaktion eine S-Sperre für ein Datenzeilenobjekt erhält, muss sie zuerst eine IS-Sperre oder eine stärkere Sperre für die Tabelle erhalten.
Bevor eine Transaktion eine X-Sperre für ein Datenzeilenobjekt erhält, muss sie zuerst eine IX-Sperre für die Tabelle erhalten.
Durch die Einführung von Intention-Locks muss Transaktion T, wenn sie eine X-Sperre zu Tabelle A hinzufügen möchte, zunächst nur feststellen, ob andere Transaktionen eine X/IX/S/IS-Sperre zu Tabelle A hinzugefügt haben. Wenn dies der Fall ist, bedeutet dies, dass andere Transaktionen die Sperre für diese Tabelle oder eine Zeile in der Tabelle verwenden, sodass Transaktion T keine X-Sperre hinzufügen kann.

Alle IS/IX-Sperren sind zueinander kompatibel, da sie nur den Wunsch anzeigen, die Tabelle zu sperren, nicht aber die eigentliche Sperre.
Die Kompatibilitätsbeziehung besteht hier für Sperren auf Tabellenebene, und die IX-Sperre auf Tabellenebene ist mit der X-Sperre auf Zeilenebene kompatibel. Zwei Transaktionen können zwei Datenzeilen X-Sperren hinzufügen.
(Transaktion T1 möchte eine X-Sperre zur Datenzeile R1 hinzufügen, und Transaktion T2 möchte eine X-Sperre zur Datenzeile R2 in derselben Tabelle hinzufügen. Beide Transaktionen müssen der Tabelle eine IX-Sperre hinzufügen, aber IX-Sperren sind kompatibel, und IX-Sperren sind auch mit X-Sperren auf Zeilenebene kompatibel. Daher können beide Transaktionen erfolgreich zwei Datenzeilen in derselben Tabelle sperren und ändern.)

7.Implizite und explizite Sperren von MySQL

Implizite Sperrung: Die InnoDB-Speicher-Engine von MySQL verwendet ein zweistufiges Sperrprotokoll, das bei Bedarf entsprechend der Isolationsstufe automatisch sperrt und alle Sperren gleichzeitig aufhebt. Dies wird als implizite Sperrung bezeichnet.

Zweistufiges Sperrprotokoll: Sperren und Entsperren sind in zwei Stufen unterteilt. Serialisierbare Planung bedeutet, dass durch Parallelitätskontrolle die Ergebnisse gleichzeitig ausgeführter Transaktionen mit den Ergebnissen einer seriell ausgeführten Transaktion identisch sind. Seriell ausgeführte Transaktionen stören sich nicht gegenseitig und es treten keine gleichzeitigen Konsistenzprobleme auf.

Oder verwenden Sie eine bestimmte Anweisung, um eine explizite Sperre durchzuführen: SELECT ... LOCK Im SHARE MODE; (gemeinsame Sperre) SELECT ... FOR UPDATE; (exklusive Sperre) Die Sperre wird automatisch aufgehoben, nachdem die Transaktion abgeschlossen und festgeschrieben wurde.

MySQL-Drei-Ebenen-Blockierungsprotokoll

Sperrprotokoll der Ebene 1: Wenn Transaktion T Daten A ändern möchte, muss sie eine X-Sperre hinzufügen und die Sperre erst nach Beendigung von Transaktion T aufheben, um das Problem verlorener Änderungen zu lösen. Zu diesem Zeitpunkt können zwei Transaktionen nicht gleichzeitig dieselben Daten ändern, da sonst die Änderungen der Transaktionen nicht überschrieben werden.

Sperrprotokoll der Stufe 2: Basierend auf dem Protokoll der Stufe 1 muss beim Lesen von Daten A eine S-Sperre hinzugefügt werden. Das Aufheben der S-Sperre unmittelbar nach dem Lesen kann das Problem des Lesens fehlerhafter Daten lösen. Denn wenn eine Transaktion Daten A ändert, wird gemäß dem Sperrprotokoll der Ebene 1 eine X-Sperre hinzugefügt und anschließend kann keine S-Sperre hinzugefügt werden. Dies bedeutet, dass keine fehlerhaften Daten eingelesen werden.

Sperrprotokoll der Stufe 3: Basierend auf dem Protokoll der Stufe 2 muss beim Lesen von Daten eine S-Sperre hinzugefügt werden, und die S-Sperre kann erst freigegeben werden, nachdem die Transaktion abgeschlossen ist. Die S-Sperre kann das Problem nicht wiederholbarer Lesevorgänge lösen, da beim Lesen von A andere Transaktionen keine X-Sperre zu A hinzufügen können, wodurch Datenänderungen während des Lesens vermieden werden.

8. Sperrimplementierung der InnoDB-Engine

MVCC

Die Multiversion Concurrency Control ist eine spezielle Methode für die innoDB-Speicher-Engine von MySQL, um Isolationsebenen zu implementieren. Sie kann verwendet werden, um die beiden Isolationsebenen „Commited Read“ und „Repeatable Read“ zu implementieren. Die Isolationsebene „Uncommited Read“ liest immer die neueste Datenzeile, was sehr geringe Anforderungen stellt und die Verwendung von MVCC nicht erfordert.

Wie im Abschnitt zum Sperren erwähnt, können durch Sperren die Konsistenzprobleme gelöst werden, die bei der gleichzeitigen Ausführung mehrerer Transaktionen auftreten. In tatsächlichen Szenarien gibt es häufig mehr Lesevorgänge als Schreibvorgänge. Daher werden Lese-/Schreibsperren eingeführt, um unnötige Sperrvorgänge zu vermeiden. Beispielsweise schließen sich Lesen und Schreiben nicht gegenseitig aus. Bei einer Lese-/Schreibsperre schließen sich Lese- und Schreibvorgänge immer noch gegenseitig aus, und MVCC verwendet die Idee mehrerer Versionen. Schreibvorgänge aktualisieren den Snapshot der neuesten Version, während Lesevorgänge den Snapshot der alten Version lesen. Es gibt keine gegenseitige Ausschlussbeziehung, was CopyOnWrite ähnelt.

In MVCC fügt der Änderungsvorgang (DELETE, INSERT, UPDATE) einer Transaktion der Datenzeile einen Versions-Snapshot hinzu. Der grundlegendste Grund für Dirty Reads und nicht wiederholbare Lesevorgänge besteht darin, dass eine Transaktion nicht festgeschriebene Änderungen aus anderen Transaktionen liest. Wenn eine Transaktion einen Lesevorgang ausführt, legt MVCC zur Lösung der Probleme von Dirty Reads und nicht wiederholbaren Lesevorgängen fest, dass nur festgeschriebene Snapshots gelesen werden können. Natürlich kann eine Transaktion ihren eigenen nicht festgeschriebenen Snapshot lesen, was nicht als Dirty Read gilt.

Systemversionsnummer SYS_ID: Es handelt sich um eine steigende Zahl. Bei jedem Start einer neuen Transaktion erhöht sich die Systemversionsnummer automatisch.

Transaktionsversionsnummer TRX_ID: Die Systemversionsnummer beim Start der Transaktion.

Mit der Multiversion von MVCC sind mehrere Versionen von Snapshots gemeint, die im Undo-Log gespeichert werden. Das Log verbindet alle Snapshots einer Datenzeile über den Rollback-Pointer ROLL_PTR.

INSERT-, UPDATE- und DELETE-Operationen erstellen ein Protokoll und schreiben die Transaktionsversionsnummer TRX_ID. DELETE kann als spezielles UPDATE betrachtet werden, das das DEL-Feld ebenfalls auf 1 setzt.

LesenAnzeigen

MVCC verwaltet eine ReadView-Struktur, die hauptsächlich die Liste der nicht festgeschriebenen Transaktionen im aktuellen System sowie die Minimal- und Maximalwerte der Liste enthält.

Beim Ausführen einer SELECT-Operation wird die Beziehung zwischen der TRX_ID des Datenzeilen-Snapshots und TRX_ID_MIN und TRX_ID_MAX verwendet, um zu bestimmen, ob der Datenzeilen-Snapshot verwendet werden kann.

TRX_ID < TRX_ID_MIN, was darauf hinweist, dass der Datenzeilen-Snapshot vor allen aktuellen nicht festgeschriebenen Transaktionen geändert wurde und daher verwendet werden kann.

TRX_ID > TRX_ID_MAX, was darauf hinweist, dass der Datenzeilen-Snapshot nach dem Start der Transaktion geändert wurde und daher nicht verwendet werden kann.

TRX_ID_MIN <= TRX_ID <= TRX_ID_MAX, muss entsprechend der Isolationsstufe beurteilt werden

Festgelegtes Lesen: Wenn sich TRX_ID in der TRX_IDs-Liste befindet, bedeutet dies, dass für die dem Datenzeilen-Snapshot entsprechende Transaktion kein Festschreiben durchgeführt wurde und der Snapshot daher nicht verwendet werden kann. Andernfalls ist es eingereicht und kann verwendet werden.

Wiederholbares Lesen: Keines von beiden kann verwendet werden. Denn wenn es verwendet werden kann, können auch andere Transaktionen diesen Datenzeilen-Snapshot lesen und ändern, sodass sich der von der aktuellen Transaktion beim Lesen dieser Datenzeile erhaltene Wert ändert, was bedeutet, dass ein nicht wiederholbares Leseproblem auftritt. Wenn der Datenzeilen-Snapshot nicht verfügbar ist, müssen Sie dem Rollback-Zeiger ROLL_PTR des Undo-Protokolls folgen, um den nächsten Snapshot zu finden und dann die obige Beurteilung durchzuführen.

Snapshot-Lesen und sicheres Lesen

Snapshot lesen: Der Auswahlvorgang von MVCC sind die Daten im Snapshot und es ist kein Sperrvorgang erforderlich.

Aktuelles Lesen: Andere Operationen von MVCC, die die Datenbank ändern, erfordern Sperrvorgänge, um die neuesten Daten zu lesen. Es ist ersichtlich, dass MVCC das Sperren nicht vollständig vermeidet, sondern nur den Sperrvorgang der Auswahl vermeidet

Wenn Sie eine Sperre auswählen müssen, können Sie einen Sperrvorgang erzwingen, beispielsweise die zuvor erwähnte gemeinsame Sperre und die exklusive Sperre.

Next-Key-Schlösser

Konzept: Next-Key Locks ist eine Sperrimplementierung der InnoDB-Speicher-Engine von MySQL. MVCC kann das Phantomleseproblem nicht lösen, und zur Lösung dieses Problems gibt es Next-Key Locks. Auf der Isolationsebene REPEATABLE READ kann die Verwendung von MVCC + Next-Key Locks das Phantomleseproblem lösen.

Datensatzsperren: Sperrt einen Index für einen Datensatz, nicht den Datensatz selbst. Wenn die Tabelle keinen Index hat, erstellt InnoDB automatisch einen versteckten gruppierten Index für den Primärschlüssel.

Lückensperren: Sperrt die Lücken zwischen den Indizes, aber nicht die Indizes selbst. Wenn beispielsweise eine Transaktion die folgende Anweisung ausführt: SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key-Sperren: Es handelt sich um eine Kombination aus Datensatzsperren und Lückensperren, die nicht nur den Index eines Datensatzes, sondern auch die Lücke zwischen den Indizes sperrt. Es sperrt einen Bereich, der vorne offen und hinten geschlossen ist. Wenn ein Index beispielsweise die folgenden Werte enthält: 10, 11, 13 und 20, muss der folgende Bereich gesperrt werden: (-∞, 10](10, 11](11, 13](13, 20](20, +∞)

IX. Fazit

Die oben genannten Theorien sind zahlreich, unterstützen aber auch den gesamten Forschungs- und Entwicklungsprozess. Wenn verschiedene Geschäftsszenarien auftreten, muss beurteilt werden, ob Transaktionen Deadlocks, Dateninkonsistenzen und andere theoretische Probleme basierend auf der Isolationsstufe der Datenbank verursachen. Die leistungsstärkste Funktion von MySQL besteht darin, dass Phantomlesevorgänge auf der RR-Ebene (Repeatable Read) vermieden werden, wodurch sowohl die Leistung als auch die Datensicherheit berücksichtigt werden.
Bei der Entwicklung von Microservices oder verteilten Projekten. Versuchen Sie, Transaktionen so einfach wie möglich zu schreiben, damit sie die entsprechenden Zeilen nicht für längere Zeit sperren. Dadurch wird auch die Datenkonsistenz sichergestellt

Dies ist das Ende dieses Artikels zur eingehenden Analyse von MySQL-Datenbanktransaktionen und -Sperren. Weitere relevante MySQL-Datenbanktransaktionen und -Sperren finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!