Der Mechanismus von MySQL-Datenbanktransaktionen [Zusammenfassung]

In den letzten Tagen wurde ich oft nach Datenbanktransaktionsmechanismen, Isolationsstufen, optimistischen Sperren und pessimistischen Sperren gefragt Ich verstehe sie nicht und habe deshalb mit „Nicht gut“ geantwortet. Ich habe das Buch später zum Studieren durchgelesen und einige Dinge verstanden, deshalb werde ich es hier aufzeichnen.

Was ist eine Transaktion?

Was ich unter einer Transaktion verstehe, ist ein vollständiges Geschäftsverhalten. Ein Geschäftsverhalten kann mehrere Aktionen umfassen. Ein klassischeres Beispiel ist eine Banküberweisung. Die Übertragung von Konto A auf Konto B erfordert zwei Aktionen: Abheben von Konto A und Hinzufügen zu Konto B. Es muss sichergestellt werden, dass beide oder keine dieser Aktionen ausgeführt werden.

Transaktionen haben ACID-Eigenschaften, einschließlich:

● Atomarität (Atomizität): Atomarität bedeutet, dass Transaktionen unteilbar sind, entweder alle erfolgreich oder alle fehlgeschlagen, nicht teilweise erfolgreich und teilweise fehlgeschlagen. Im Falle eines Fehlers auf halbem Weg muss das Schlachtfeld bereinigt werden, das heißt, die Daten werden zurückgesetzt.

● Konsistenz: Konsistenz bezieht sich auf das Endergebnis einer Transaktion und stellt sicher, dass es keine Anomalien in den Daten gibt. Konsistenz legt Wert auf Ergebnisse und basiert auf Atomizität. Das heißt, wenn Atomizität garantiert werden kann, werden konsistente Ergebnisse erzielt.

● Isolation: Isolation bedeutet, dass eine Transaktion vor der Übermittlung für andere Transaktionen nicht sichtbar ist und die Daten zwischen Transaktionen isoliert sind (natürlich ist der Grad der Isolation auf verschiedenen Ebenen unterschiedlich).

● Haltbarkeit: Nachdem die Transaktion übermittelt wurde, bleibt sie bestehen und kann lange gespeichert werden.

Transaktionsisolationsstufe

Bevor Sie die Isolationsstufe einer Transaktion verstehen, müssen Sie mehrere Konzepte des Datenlesens verstehen:

● Schmutziges Lesen: Es bedeutet, Daten zu lesen, die andere noch nicht übermittelt haben.

● Wiederholbares Lesen: Es handelt sich um zwei Abfragen innerhalb derselben Sache. Wenn jemand anderes den Datensatz in der Abfrage ändert und ihn übermittelt, ist er für die zweite Abfrage nicht sichtbar und derselbe Datensatz wird nicht angezeigt Zwei Abfragen sind inkonsistent.

● Phantomlesung: Es handelt sich um zwei Abfragen innerhalb einer Sache. Wenn jemand anderes einen Datensatz hinzufügt und ihn in der Mitte übermittelt, stimmt das, was in der zweiten Abfrage gefunden wird, nicht mit dem ersten Datensatz überein.

Die Transaktionskontrolle ist in viele Ebenen unterteilt. Die Ebene bestimmt den Grad der Isolation. Es gibt vier Ebenen in MySQL:

● Nicht festgeschrieben lesen: Diese Ebene ist Auf der niedrigsten Ebene ist die Änderung von Transaktion A nicht festgeschrieben, sie ist für Transaktion B sichtbar und es kommt zu einem fehlerhaften Lesen von Daten. Dieser Typ wird im Allgemeinen nicht verwendet.

● Gesendet lesen: Die Änderung von Ding A ist für B erst sichtbar, nachdem es übermittelt wurde. In diesem Fall tritt das Problem des Phantomlesens von Daten auf und die Ergebnisse der beiden Abfragen sind unterschiedlich.

● Wiederholbares Lesen: Dies ist die Standardebene von MySQL. Zwischen zwei Abfragen wird in der Mitte ein bestimmter Datensatz geändert, der für andere Transaktionen unsichtbar ist, wodurch sichergestellt wird, dass derselbe Datensatz konsistent ist , aber andere Transaktionen sind für neue Hinzufügungen sichtbar, sodass weiterhin neue Phantom-Lesevorgänge stattfinden.

● Serialisierbar: Transaktionen werden seriell ausgeführt und jeder abgefragte Datensatz wird blockiert, und die Parallelität führt zu schwerwiegenden Leistungsproblemen. Daher wird dieser Typ im Allgemeinen nicht verwendet.

Übersicht über die Isolationsebene

Isolierungsimplementierung von Transaktionen

Transaktionsisolation wird gesteuert Auf zwei Arten: Die eine ist die Sperrmethode, die eine Isolierung durch zeitliche Trennung erreicht, die andere ist die Versionskontrollmethode, die mehrere Versionen aufzeichnet, um eine Isolierung zu erreichen.

1. Sperren

Die Sperren in MySQL werden in Lesesperren und Schreibsperren unterteilt. Da Lesesperren Daten lesen, können mehrere Lesevorgänge derselben Daten durchgeführt werden Gleichzeitig hat es einen gemeinsamen Charakter; die Schreibsperre beinhaltet Datenänderungen, sodass sie mit anderen Schreibsperren und Lesesperren in Konflikt steht und einen exklusiven Charakter hat.

In Bezug auf die Sperrgranularität kann es in Sperren auf Tabellenebene und Sperren auf Zeilenebene unterteilt werden. Tabellensperren treten im Allgemeinen auf, wenn die Tabellenstruktur geändert oder die gesamte Tabelle aktualisiert wird, und blockieren alle Lese- und Schreibvorgänge Schreibvorgänge für diese Tabelle erfolgen im Allgemeinen, wenn ein angegebener Datensatz aktualisiert wird, und nur der angegebene Datensatz wird gesperrt. Je kleiner die Sperrgranularität, desto höher sollten Sperren auf Zeilenebene priorisiert werden und Tabellensperren sollten so weit wie möglich vermieden werden. Dies ist das gleiche Prinzip wie die Sperrgranularität im Programm.

2. Parallelitätskontrolle mehrerer Versionen

Aus Leistungsgründen verfügt MySQL neben der Sperrung auf Zeilenebene über eine weitere Methode, die Parallelitätskontrolle mehrerer Versionen, die durch den Speicher gesteuert wird Engine-Implementierung.

Das Buch erklärt eine einfache Implementierungsmethode von InnoDB. Diese Methode verwendet einen Datensatz mit mehreren Versionen. Zu jedem Datensatz werden zwei versteckte Spalten hinzugefügt, eine ist die Erstellungsversionsnummer und die andere ist die Versionsnummer. Bei jedem Öffnen einer Transaktion wird eine Transaktionsversionsnummer zugewiesen und die Vorgänge innerhalb der Transaktion werden anhand dieser Versionsnummer verglichen. Die Details lauten wie folgt:

● Bei der Abfrage: Fragen Sie die Datensätze ab, die vor der aktuellen Transaktion vorhanden waren, und die Datensätze, die durch diese Transaktion erstellt wurden und nicht gelöscht wurden, d. h.: Versionsnummer erstellen Aktuelle Versionsnummer)

● Beim Einfügen: Die aufgezeichnete Erstellungsversionsnummer ist die aktuelle Transaktionsversionsnummer.

● Beim Löschen: Die gelöschte Versionsnummer des Aktualisierungsdatensatzes ist die aktuelle Transaktionsversionsnummer.

● Beim Aktualisieren: Fügen Sie einen neuen Datensatz ein, erstellen Sie die Versionsnummer als aktuelle Transaktionsversionsnummer und ändern Sie die gelöschte Versionsnummer des ursprünglichen Datensatzes in die aktuelle Transaktionsversionsnummer, was bedeutet, dass er gelöscht wurde. Tatsächlich entspricht die Aktualisierung hier dem Löschen und Hinzufügen eines weiteren Datensatzes.

3. Optimistische Schlösser und pessimistische Schlösser

Aus Sicht der Verwendung werden pessimistische Schlösser und optimistische Schlösser unterteilt, und ich denke, sie haben eine sehr pessimistische Einstellung Die gefundenen Daten können von anderen geändert werden. Daher wird dieser Datenstapel beim Abfragen gesperrt, um zu verhindern, dass andere ihn bedienen. Das optimistische Sperren ist sehr optimistisch und glaubt, dass es grundsätzlich unmöglich ist, dass die von mir gefundenen Daten von anderen geändert werden Ändern Sie, damit dieser Datenstapel bei der Abfrage nicht gesperrt wird. Überprüfen Sie beim Absenden, ob die Änderung von anderen vorgenommen wurde.

Implementierung von optimistischem Sperren und pessimistischem Sperren:

● Pessimistisches Sperren kann leicht auf Datenbankebene gelöst werden, indem bei der Abfrage „Just lock“ mit „select...“ zum Aktualisieren verwendet wird Dieser Teil der Daten.

● Die Implementierung der optimistischen Sperre ist komplizierter als die der pessimistischen Sperre. Sie können eine Versionsnummernspalte in die Datenbank einfügen. Bei der Aktualisierung lautet die Versionsnummer +1, um zu bestätigen, ob die von mir gefundenen Daten geändert wurden Von anderen geänderte Dateien werden nicht aktualisiert oder das Programm löst eine Ausnahme aus.

Sollten wir optimistisches Sperren oder pessimistisches Sperren verwenden:

Aus Sicht der Leistung ist optimistisches Sperren besser, es gibt jedoch keinen Sperrvorgang zwischen Abfrage und Aktualisierung schwierig zu implementieren. Nicht so einfach wie pessimistisches Sperren und kann schief gehen. Der zu berücksichtigende Faktor ist also, ob die Parallelität des Systems hoch ist. Wie groß ist die Konfliktwahrscheinlichkeit? Wenn die Parallelität hoch ist, ist es besser, optimistische Sperren zu verwenden, andernfalls ist es besser, eine einfache Methode wie pessimistische Sperren zu verwenden.

Empfohlenes MySQL-Video-Tutorial, Adresse: https://www.php.cn/course/list/51.html

Das obige ist der detaillierte Inhalt vonDer Mechanismus von MySQL-Datenbanktransaktionen [Zusammenfassung]. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!