Vorwort
Welche Beziehung besteht zwischen Isolationsstufe und Datenbanksperre?
Dieser Artikel wird mit Ihnen über die Verbindung zwischen den beiden sprechen, ich hoffe, es wird Ihnen helfen!
Sprechen Sie über die Verbindung zwischen den beiden
Bevor wir im Detail sprechen, erinnern wir uns an einen Satz: Datenbanktransaktionen haben unterschiedliche Isolationsstufen, und verschiedene Isolationsstufen verwenden Sperren unterschiedlich. Die Anwendung von Sperren führt letztendlich zu Isolationsstufen verschiedener Transaktionen.
Lassen Sie uns zunächst die vier Isolationsstufen verstehen
- Read Uncommitted: (Read Uncommitted)
- Read Committed Die Standardisolationsstufe für die meisten Datenbanken
- Repeatable-Read (Repeatable-Read) Standardstufe der MySQL-Datenbank
- Serialisierbar
Die spezifische Implementierung und Unterschiede der vier Isolationsstufen
Erstens können Programme gleichzeitig ausgeführt werden. Ebenso kann in MySQL eine Tabelle von zwei oder mehr Prozessen gleichzeitig gelesen und geschrieben werden, was kein Problem ist.
Wenn zum Beispiel zu diesem Zeitpunkt zwei Prozesse zum Lesen von Daten vorhanden sind, gibt es kein Problem, sodass dies zulässig ist. Wenn jedoch ein Prozess gerade eine Datenzeile liest und ein anderer Prozess Daten in diese Zeile schreibt (ändert, löscht), was ist das Ergebnis?
Wenn zwei Prozesse gleichzeitig Änderungen an einer Datenzeile vornehmen, wessen Änderung soll dann Vorrang haben? Was das Ergebnis sein wird, kann ich mir nicht vorstellen, wenn die Daten zerstört werden. Derzeit gibt es also einen Konflikt.
Da der Konflikt und das Finden einer Lösung, auf die man sich verlässt, um zu lösen, ist diesmal durch Sperrmechanismus zu warten. Wie kann man Sperren verwenden, um Konflikte zu vermeiden?
Zu Beginn der Transaktion können Sie der zu schreibenden Datenzeile eine exklusive Sperre hinzufügen. Wenn es sich um eine Leseoperation handelt, geben Sie der Datenzeile eine Lesesperre. Danach dürfen beim Ändern der Datenzeile keine anderen Prozesse Operationen an der Datenzeile ausführen.
Beim Lesen der Datenzeile können andere Prozesse diese nicht ändern, aber lesen. Wenn das Lesen oder Schreiben abgeschlossen ist, wird die Sperre aufgehoben und schließlich das Commit gesendet. Zu diesem Zeitpunkt sind Lesen und Schreiben getrennt, und Schreiben und Schreiben sind getrennt.
MySQL-Entwickler, die dieses Konfliktlösungsprogramm angeben, haben den Namen: read uncommitted : (Read Uncommitted). Dies ist die erste Isolierung der Transaktion.
Hinweis: Der oben beschriebene Vorgang zum Sperren und Freigeben der Sperre wird von der MySQL-Datenbank selbst ohne unser menschliches Eingreifen verwaltet
Aber dieser Grad an Isolation reicht einfach nicht aus. Siehe die Testergebnisse unten
1. Eine geänderte Transaktionsebene ist: nicht festgeschriebenes Lesen. Starten Sie die Transaktion und führen Sie eine Abfrage in der Benutzertabelle durch:
2. Transaktion B aktualisiert einen Datensatz:
3. Zu diesem Zeitpunkt wurde Transaktion B noch nicht gesendet, und A führt eine Abfrage innerhalb der Transaktion durch und stellt fest, dass sich das Abfrageergebnis geändert hat:
4. B führt einen Transaktions-Rollback durch:
5. Wenn A eine weitere Abfrage durchführt, wird das Abfrageergebnis zurück geändert:
Gemäß dem Experiment: Bei der Transaktion eines Prozesses habe ich eine Datenzeile geändert, aber nachdem ich sie geändert habe, wurde die Sperre aufgehoben. Zu diesem Zeitpunkt liest ein anderer Prozess die Daten und die vorherige Transaktion ist noch nicht festgeschrieben. Ja Bis ich die Daten zurücksetze, werden die von einem anderen Prozess gelesenen Daten zu nutzlosen oder falschen Daten.
Wir nennen diese Daten normalerweise Dirty Data, diese Daten werden Zang Read genannt .
Wie es geht? Natürlich kommt es immer noch auf den Verriegelungsmechanismus an.
Es ist nichts weiter als der Speicherort der Sperre. Bisher wurde die Sperre sofort freigegeben, solange die Daten manipuliert wurden. Jetzt wird der Speicherort der Sperre nach dem Festschreiben der Transaktion angepasst. Zu diesem Zeitpunkt, bevor die Transaktion festgeschrieben wird, Andere Prozesse können die Daten in der Zeile nicht ausführen. Lesen, einschließlich Operationen.
Dann gab die Datenbank einen Namen für die Datenbankbetriebsregeln für diesen Status an: Read Committed (Read Committed), oder Sie können nicht wiederholbares Lesen aufrufen. Dies ist die zweite Isolierung der Transaktion.
In einigen Fällen ist das nicht wiederholbare Lesen kein Problem. Wenn wir beispielsweise bestimmte Daten mehrmals abfragen, ist das Ergebnis der endgültigen Abfrage natürlich das wichtigste. In anderen Fällen können jedoch Probleme auftreten. Wenn beispielsweise dieselben Daten A und B nacheinander abgefragt werden, können sie unterschiedlich sein und A und B können kämpfen ...
Fahren Sie fort, um die Testergebnisse unten zu sehen
1. Passen Sie die Isolation auf READ-COMMITTED (gelesenen Inhalt lesen) an, legen Sie die Transaktionsisolationsstufe von A fest und geben Sie die Transaktion ein, um eine Abfrage durchzuführen:
2. B startet die Transaktion und ändert den Datensatz:
3. A fragt die Benutzertabelle erneut ab und stellt fest, dass der Datensatz nicht betroffen ist:
4. B schreibt die Transaktion fest:
5. A fragt die Benutzertabelle erneut ab und stellt fest, dass der Datensatz geändert wurde:
An diesem Punkt des Experiments werden Sie feststellen, dass die Endergebnisse inkonsistent sind, wenn dieselben Daten in derselben Transaktion zweimal gelesen werden.
Hier nennen wir dieses Phänomen: nicht wiederholbares Lesen . Denn nachdem die erste Transaktion die Daten gelesen hat, ändert eine andere Transaktion die Daten zu diesem Zeitpunkt. Zu diesem Zeitpunkt wird die Transaktion festgeschrieben. Wenn die zweite Transaktion die Daten zum zweiten Mal liest, ist das Ergebnis anders. Vor einer Änderung Ja, eine wird überarbeitet.
Wenn Sie jedoch vorsichtig sind, werden Sie feststellen, dass, da Sie gesagt haben, dass diese Art der Isolierung die Sperre aufheben soll, nachdem die Transaktion festgeschrieben wurde, im Testprozess, bevor die Daten nicht festgeschrieben werden, warum eine andere Transaktion noch gelesen werden kann.
Ist der obige Test falsch? Nein;
Hier verwendet mysql einen Mechanismus zur gleichzeitigen Versionskontrolle, sie nennen ihn MVCC, in Laienbegriffen: mysql, um die Parallelität des Systems zu verbessern, bevor die Transaktion nicht festgeschrieben wird, obwohl die innerhalb der Transaktion betriebenen Daten gesperrt sind, andere Transaktionen jedoch Lesen Sie weiterhin die Daten- Snapshot-Version , die meisten Datenbanken wie Oracle usw. lesen standardmäßig die Übermittlung dieser Isolationsstufe.
Die Standardisolationsstufe von MySQL ist jedoch nicht diese
Dieses Problem tritt nicht nur beim Aktualisieren von Daten wie oben auf, sondern verursacht auch ein ähnliches Phänomen beim Einfügen von Daten: Obwohl MySQL die Betriebsdatenzeile sperrt, verhindert es immer noch nicht, dass eine andere Transaktion in die Tabelle Neue Zeile mit neuen Daten eingefügt wird.
Beispiel: Eine Transaktion liest oder aktualisiert alle Zeilen in der Tabelle, und der Empfänger verfügt über eine andere Transaktion, um eine neue Zeile in die Tabelle einzufügen, nachdem die Transaktion festgeschrieben wurde.
Die Transaktion, die die Daten ursprünglich gelesen oder geändert hat, liest dieselben Daten ein zweites Mal. Zu diesem Zeitpunkt ist die Anzahl der Zeilen in der Ergebnismenge, die in dieser Transaktion zweimal gelesen wurden, unterschiedlich. Alle Zeilen wurden aktualisiert, aber jetzt habe ich es gelesen und festgestellt, dass es noch eine Zeile gibt, die nicht aktualisiert wurde. Dies wird als Phantom Reads bezeichnet .
Wie gehen Sie als Nächstes vor, um zu verhindern, dass inkonsistente Daten zweimal in derselben Transaktion gelesen werden (einschließlich nicht erneut lesbarer Daten und Phantom-Lesevorgänge)?
MySQL verwendet weiterhin die gleichzeitige MVCC-Versionskontrolle, um dieses Problem zu lösen oder Snapshot-Daten zu lesen.
Insbesondere: Wenn eine Transaktion mehrere Lesevorgänge derselben Daten enthält, liest MySQL beim ersten Lesen weiterhin die Daten der zuletzt festgeschriebenen Transaktion. Nach dem ersten Mal und späterem Lesen nimmt MySQL Das erste Mal. Die gelesenen Daten sind das Ergebnis.
Dies stellt die Datenkonsistenz sicher, wenn dieselbe Transaktion Daten mehrmals liest. Derzeit wird diese Lösung als mysql bezeichnet: Wiederholbares Lesen (Repeatable-Read). Dies ist die dritte oben beschriebene Isolation. Mysql ist die Standardisolationsstufe.
Hinweis: Unter der Isolationsstufe für wiederholbares Lesen wird nicht nur die Konsistenz des Lesevorgangs sichergestellt, sondern auch die Konsistenz der Daten während des Aktualisierungsvorgangs (aktuelles Lesen) gewährleistet, um nicht wiederholbare Lese- und Phantomlesefehler zu vermeiden.
Insbesondere: Unter der wiederholbaren Leseisolationsstufe von MySQL werden Daten in einer Transaktion aktualisiert, und die Transaktion wird nicht festgeschrieben, und eine weitere Transaktionseinfügung wird gestartet, um neue Daten einzufügen. Derzeit ist es nicht möglich, neue Daten und die Einfügung einzufügen Der Betrieb ist blockiert. Warum ist er blockiert? Was ist mit dem Blockieren?
Da die Daten aktualisiert werden, wenn die erste Transaktion (aktueller Lesevorgang) Zeilensperren + gesperrte Lückensperrentabelle verwendet, wird die Einfügeoperation der zweiten Transaktion blockiert, und erst nachdem die erste Transaktion festgeschrieben wurde, kann die Einfügeoperation in der zweiten Transaktion ausgeführt werden ;;
Wenn es nicht blockiert ist, was ist das Problem? Es wird Phantom-Leseprobleme geben , zum Beispiel: Es wäre eine feldübergreifende Tabelle aller Daten aktualisiert worden, aber aufgrund der hinzugefügten Daten hinter diesem neuen Datenfeld, die nicht aktualisiert wurden, genau wie beim erneuten Anzeigen Die Illusion ist dieselbe: Um das Problem der Phantom-Lesevorgänge zu lösen, werden Lückensperren in der Isolationsstufe für wiederholbare Lesevorgänge bereitgestellt, und Zeilensperren + Lückensperren werden verwendet, um die Tabelle zu sperren, sodass nicht alle Operationen die Daten ändern können.
Hinweis: Die innodb-Speicher-Engine verfügt über eine Konfiguration für die Wartezeit für Sperren. Wenn die Sperre nicht innerhalb der angegebenen Zeit erreicht wird, wird die Transaktion unterbrochen und der Anwendungscode muss manuell zurückgesetzt oder erneut versucht werden.
Hinweis: Der Unterschied zwischen Phantom-Lesen und nicht wiederholbarem Lesen:
- Der Phantomwert gilt für einen Stapel von Datensätzen als Ganzes
- Das nicht wiederholbare Lesen gilt für die Datensätze desselben Datenelements
Zu diesem Zeitpunkt ist unsere letzte Isolationsstufe auch die höchste Isolationsstufe: Serialisieren Sie das Debüt nicht (serialisierbar)
Die Isolationsstufe sperrt automatisch die Daten der gesamten Tabelle, die Sie betreiben möchten. Wenn eine andere Prozesstransaktion Daten in der Tabelle bearbeiten möchte, muss sie warten, bis der Prozess die Sperre erhalten hat, um den Vorgang zum Aufheben der Sperre abzuschließen.
Kann schmutzige Lesevorgänge, nicht wiederholbare Lesevorgänge und Phantom-Lesevorgänge vermeiden. Natürlich wird die Leistung stark sinken, was dazu führt, dass viele Prozesse in die Warteschlange gestellt werden, um um Sperren zu konkurrieren.
Nachtrag
Die vier oben genannten isolierten Sperrmechanismusanwendungen werden von der Datenbank automatisch ohne menschliches Eingreifen vervollständigt.
Die Einstellung für die Isolationsstufe gilt nur für die aktuelle Sitzungsverbindung. Bei Verwendung des MySQL-Befehlsfensters entspricht ein Fenster einer Verknüpfung, und die im aktuellen Fenster festgelegte Isolationsstufe gilt nur für die Transaktionen im aktuellen Fenster.