Beispielanalyse des Prinzips der MySQL-Transaktionsisolationsebene

1. Nicht festgeschriebene Daten lesen (READ_UNCOMMITTED)

Tatsächlich ist dies aus dem Namen der Isolation ersichtlich: Eine Transaktion kann die nicht festgeschriebenen Daten einer anderen Transaktion lesen! Zur Erklärung zeichne ich einfach ein Bild zur Veranschaulichung!

Wie in der Abbildung gezeigt, wurden die von einer Transaktion abgerufenen Daten von einer anderen, nicht festgeschriebenen Transaktion geändert.

Die von der offiziellen Website für Dirty Read definierte Adresse lautet

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_dirty_read

Sein Inhalt ist

**schmutzige Lektüre
Ein Vorgang, bei dem unzuverlässige Daten abgerufen werden, d. h. Daten, die durch eine andere Transaktion aktualisiert, aber noch nicht festgeschrieben wurden.
**

Übersetzt bedeutet es

Die aus der Operation abgerufenen Daten sind unzuverlässig und können durch eine andere nicht festgeschriebene Transaktion geändert werden!

Sie werden feststellen, dass die Ergebnisse unserer Demonstration mit der Definition von „Dirty Reads“ auf der offiziellen Website übereinstimmen. Gemäß unserer anfänglichen Argumentation müssen, wenn Dirty Reads existieren, nicht wiederholbare Reads und Phantom Reads existieren.

2. Lesen verpflichtet (READ_COMMITTED)

Dies zeigt auch, dass eine Transaktion die von einer anderen Transaktion übermittelten Daten lesen kann! Zur Erklärung zeichne ich einfach ein Bild zur Veranschaulichung!

Wie in der Abbildung gezeigt, können von einer Transaktion abgerufene Daten nur von einer anderen festgeschriebenen Transaktion geändert werden.

Die von der offiziellen Website definierte Adresse für nicht wiederholbares Lesen ist

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_non_repeatable_read

Sein Inhalt ist

**nicht wiederholbares Lesen
Die Situation, wenn eine Abfrage Daten abruft und eine spätere Abfrage innerhalb der gleichen Transaktion zwar dieselben Daten abruft, die Abfragen jedoch unterschiedliche Ergebnisse zurückgeben (geändert durch eine andere Transaktion, die in der Zwischenzeit einen Commit ausgeführt hat).
**

Übersetzt bedeutet es

Eine Abfrageanweisung ruft Daten ab, und dann ruft eine andere Abfrageanweisung in derselben Transaktion Daten ab. Die beiden Daten sollten identisch sein, aber tatsächlich werden unterschiedliche Ergebnisse zurückgegeben. !

PS: Anmerkung des Autors: Die unterschiedlichen Ergebnisse beziehen sich hier auf die Situation, in der die Zeile unverändert bleibt (um es professioneller auszudrücken: der Primärschlüsselindex hat sich nicht geändert), sich jedoch der Dateninhalt auf der Festplatte, auf die der Primärschlüsselindex zeigt, geändert hat. Wenn sich der Primärschlüsselindex ändert, z. B. durch das Hinzufügen eines neuen Datenelements oder das Löschen eines Datenelements, handelt es sich nicht um einen nicht wiederholbaren Lesevorgang.

Offensichtlich erfüllt unser Phänomen die Definition eines nicht wiederholbaren Lesevorgangs. Lassen Sie uns als nächstes darüber nachdenken:

Diese Definition des nicht wiederholbaren Lesens kann auch auf das Phänomen des Dirty Read angewendet werden. Offensichtlich erfüllt das Phänomen des Dirty Read, also das Beispiel von **READ_UNCOMMITTED**, auch die Bedingung, in derselben Transaktion unterschiedliche Ergebnisse zurückzugeben! Der umgekehrte Fall ist jedoch nicht unbedingt der Fall. Wenn die Ergebnisse zweier Abfragen in Transaktion A durch eine andere Transaktion B geändert werden und Transaktion B das Ergebnis von Transaktion A ändert, ohne festgeschrieben zu werden, handelt es sich um einen Dirty Read und auch um einen nicht wiederholbaren Lesevorgang. Wenn Transaktion B festgeschrieben wird, bevor das Ergebnis von Transaktion A geändert wird, handelt es sich nicht um einen Dirty Read, sondern um einen nicht wiederholbaren Lesevorgang. 3. Wiederholbares Lesen (REPEATABLE_READ)

Hier ändere ich die Reihenfolge und definiere zuerst das Phantomlesen.

Die von der offiziellen Website für Phantomlesen definierte Adresse lautet

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_phantom

Phantom
Eine Zeile, die im Ergebnissatz einer Abfrage erscheint, aber nicht im Ergebnissatz einer früheren Abfrage. Beispiel: Eine Abfrage wird innerhalb einer Transaktion zweimal ausgeführt und in der Zwischenzeit führt eine andere Transaktion einen Commit aus, nachdem eine neue Zeile eingefügt oder eine Zeile aktualisiert wurde, sodass sie der WHERE-Klausel der Abfrage entspricht.

Übersetzt bedeutet es

Eine Datenzeile wird im Ergebnissatz einer Abfrage angezeigt, die Daten erscheinen jedoch nicht im Ergebnissatz einer früheren Abfrage. Beispielsweise werden zwei Abfragen in einer Transaktion ausgeführt und gleichzeitig fügt eine andere Transaktion eine Zeile ein oder aktualisiert eine Datenzeile (die Daten erfüllen die Bedingungen nach dem Where in der Abfrageanweisung) und führt einen Commit aus!

OK, schauen wir uns das Bild unten an. Sie können selbst beurteilen, ob dieses Phänomen der Definition des Phantomlesens entspricht.

Offensichtlich entspricht dieses Phänomen der Definition des Phantomlesens. Zwei identische Abfragen aus derselben Transaktion erzeugen unterschiedliche Zeilen. Lassen Sie uns als nächstes darüber nachdenken:

Diese Definition des Phantomlesens kann auch auf das Phänomen des nicht wiederholbaren Lesens angewendet werden. Denken Sie selbst darüber nach! Der Umkehrschluss ist nicht unbedingt der Fall. Die Transaktion hat zum zweiten Mal Daten abgefragt, diese sind jedoch nicht im Ergebnissatz der ersten Abfrage enthalten. Wenn es sich bei den Daten um geänderte Daten handelt, handelt es sich bei diesem Phänomen sowohl um einen nicht wiederholbaren Lesevorgang als auch um einen Phantomlesevorgang. Wenn die Daten neu hinzugefügt oder gelöscht werden, gehört dieses Phänomen nicht zum nicht wiederholbaren Lesen, sondern zum Phantomlesen.

Lassen Sie uns als Nächstes darüber sprechen, warum in vielen Artikeln die Leser falsch informiert wurden, indem behauptet wurde, dass wiederholbares Lesen das Phantomleseproblem lösen könne. Der Grund dafür ist ein Satz auf der offiziellen Website
(Die Adresse lautet: https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html#innodb-record-locks)

Der ursprüngliche Inhalt lautet wie folgt

Standardmäßig arbeitet InnoDB in der Transaktionsisolationsebene REPEATABLE READ. In diesem Fall verwendet InnoDB Next-Key-Locks für Suchvorgänge und Indexscans, wodurch Phantomzeilen verhindert werden (siehe Abschnitt 14.7.4, „Phantomzeilen“).

Nach der ursprünglichen Bedeutung dieses Satzes müsste es heißen:

InnoDB verwendet standardmäßig REPEATABLE READ. Verwenden Sie in diesem Fall Next-Key-Sperren, um das Phantomleseproblem zu lösen!

Es wird geschätzt, dass ein einheimischer Übersetzer daraus

InnoDB verwendet standardmäßig REPEATABLE READ. In diesem Fall kann das Phantomleseproblem gelöst werden!

Dann haben alle weitergemacht und ich habe Sie kopiert, und Sie kennen das Ergebnis!

Offensichtlich ändert sich die Bedeutung vollständig, wenn wir die Bedingung „Next-Key-Sperren werden verwendet!“ weglassen, und wir führen die Anweisung unter dieser Isolationsebene aus.

select * from tx_tb where pId >= 1;

Es handelt sich um einen Snapshot-Lesevorgang, der keine Sperren hinzufügt und das Phantom-Leseproblem überhaupt nicht lösen kann, es sei denn, Sie verwenden

select * from tx_tb where pId >= 1 lock in share mode;

Auf diese Weise verwenden Sie Next-Key-Sperren und lösen das Phantom-Read-Problem!

4. Serielles Lesen (SERIALIZABLE_READ)

Auf dieser Isolationsebene folgt auf alle Select-Anweisungen im Share-Modus automatisch eine Sperre. Daher werden unter dieser Isolationsebene Next-Key-Sperren verwendet, unabhängig davon, wie Sie die Abfrage durchführen. Alle Auswahlvorgänge sind aktuelle Lesevorgänge!

OK, achte auf den roten Teil in der Tabelle oben! Aufgrund der Verwendung von Next-Key-Sperren sperrt InnoDB den Indexdatensatz PiD=1 und die Lücke (1,++∞). Wenn andere Transaktionen Daten in diese Lücke einfügen möchten, werden sie blockiert. Dadurch werden Phantom-Lesevorgänge verhindert.

Manche Leute werden vielleicht sagen, dass sich das Ergebnis Ihrer zweiten Abfrage ebenfalls geändert hat und offensichtlich vom Ergebnis der ersten Abfrage abweicht. Hierzu kann ich nur sagen: Bitte schauen Sie genau hin. Das ist von sich selbst

Es wird durch die Transaktion geändert, nicht durch andere Dinge. Dies ist weder ein Phantomlesen noch ein nicht wiederholbares Lesen.

Zusammenfassen

Da oben jede Menge Unsinn steht, möchte ich eine Tabelle erstellen, um alles zusammenzufassen. Sie können diese Tabelle einfach während des Interviews beantworten. Alles oben genannte dient der Vorbereitung für diese Tabelle!

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.