serializable Serialisierung (kein Problem)
Transaktionen müssen sequenziell ausgeführt werden. Die nachfolgenden Transaktionen können nicht festgeschrieben werden, bevor die vorherige Transaktion festgeschrieben wurde. Dies ist die sicherste Methode, aber gleichzeitige Vorgänge sind nicht möglich, was zu geringer Effizienz führt.
repeatab read wiederholbares Lesen (Standardisolationsebene) (Phantomlesen)
Bevor eine Transaktion festgeschrieben wird, sind die Abfrageergebnisse unabhängig von der Anzahl der ausgeführten Abfragen dieselben (auch wenn der Datensatz durch andere Transaktionen geändert wurde), es können jedoch Phantomlesevorgänge auftreten.

Festgelegter read committed (nicht wiederholbar, Phantom-Lesevorgang)
In der aktuellen Transaktion können von anderen Transaktionen übermittelte Daten angezeigt werden, was zu einem nicht wiederholbaren Lesevorgang führen kann (nachdem ein anderer Thread Daten übermittelt hat, kann der aktuelle Thread diese sehen, und dann sind die Ergebnisse derselben SQL-Abfrage davor und danach zweimal unterschiedlich (im Vergleich zum wiederholbaren Lesevorgang)).
Auch Phantomlesen kann vorkommen Benutzer1 fragt Wangwu ab und stellt fest, dass es nicht existiert. Dann startet Benutzer2 eine Transaktion und fügt Wangwu ein, übergibt die Daten jedoch nicht. Benutzer1 fragt erneut ab und stellt immer noch fest, dass es nicht existiert. Der Vorgang zum Einfügen von Wangwu wird ausgeführt, schlägt jedoch fehl. Wangwu existiert offensichtlich nicht, kann aber nicht eingefügt werden, was zu einem Phantom-Lesevorgang führt.
Nicht festgeschriebenes read uncommitted (Phantomlesen, nicht wiederholbares Lesen, Dirty Read)
- Dirty Read: Die aktuelle Transaktion liest Daten, die nicht von anderen Transaktionen festgeschrieben wurden. Wenn andere Transaktionen zurückgesetzt werden, sind die von der aktuellen Transaktion gelesenen Daten ungültig, was als Dirty Read bezeichnet wird.
- Es kommt zu einem nicht wiederholbaren Lesevorgang: Von anderen Transaktionen übermittelte Änderungen werden von der aktuellen Transaktion erkannt, sodass die Abfrageergebnisse unterschiedlich sind.
- Phantomlesen tritt auf: Zuerst fragt Benutzer 1
wangwu ab und es existiert nicht. Benutzer 2 startet eine Transaktion und fügt wangwu ein, führt die Transaktion jedoch nicht aus. Zu diesem Zeitpunkt fragt user1 wangwu ab und stellt fest, dass es existiert.

Der Vorgang deletewangwu ist fehlgeschlagen. wangwu wurde gefunden, konnte aber nicht gelöscht werden? Dies ist das Ende dieses Artikels über die Details der MySQL-Transaktionsisolationsebenen. Weitere Informationen zu MySQL-Transaktionsisolationsebenen finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!
Das könnte Sie auch interessieren:- Tiefgreifendes Verständnis der Probleme mit der Transaktionsisolationsebene und dem Sperrmechanismus von MySQL
- MySQL Series 10 MySQL-Transaktionsisolierung zur Implementierung der Parallelitätskontrolle
- Beispielanalyse des Prinzips der MySQL-Transaktionsisolationsebene
- Detaillierte Erläuterung des Lese-Commits der MySQL-Transaktionsisolationsebene
- Tiefgreifendes Verständnis der vier Isolationsebenen von MySQL-Transaktionen
|