Beschreibung der Standardtransaktionsisolationsebene von MySQL und Oracle

1. Transaktionsmerkmale (ACID)

(1) Atomarität. Die von den an der Transaktion beteiligten Programmen durchgeführten Datenbankänderungsvorgänge sind entweder alle erfolgreich oder sie schlagen alle fehl.

(2) Konsistenz Quelle und Ziel werden vor und nach der Ausführung der Transaktion ausgeglichen.

(3) Isolierung Bei gleichzeitiger Ausführung ist jede Transaktion isoliert und beeinflusst die anderen nicht.

(4) Haltbarkeit Sobald eine Transaktion erfolgreich abgeschlossen ist, sollte die Integrität der Daten gewährleistet sein.

2. Transaktionsisolationsebene

(1) nicht festgeschrieben lesen

Alle Transaktionen können die Daten nicht festgeschriebener Transaktionen sehen.

(2) Lesen verpflichtet

Erst nach erfolgreicher Übermittlung der Transaktion kann diese abgefragt werden.

(3) Wiederholbar

Wenn mehrere Instanzen derselben Transaktion Daten lesen, werden möglicherweise nicht festgeschriebene Datensätze abgefragt, was zu Phantomlesevorgängen führt. MySQL-Standardebene

(4) Serialisierbar

Erzwingen Sie die Sortierung und fügen Sie für jede gelesene Datenzeile gemeinsame Sperren hinzu. Dies führt zu zahlreichen Zeitüberschreitungen und Sperrkonflikten.

MySQL

Die Standardtransaktionsebene von MySQL ist „REPEATABLE-READ“, was wiederholbares Lesen bedeutet.

1. Zeigen Sie die aktuelle Sitzungsisolationsstufe an

wählen Sie @@tx_isolation;

2. Zeigen Sie die aktuelle Isolationsstufe des Systems an

wählen Sie @@global.tx_isolation;

3. Legen Sie die aktuelle Sitzungsisolationsstufe fest

Festlegen der Sitzungstransaktionsisolierungsebene, wiederholbares Lesen;

4. Stellen Sie die aktuelle Isolationsstufe des Systems ein

Legen Sie die globale Transaktionsisolationsebene für wiederholbares Lesen fest.

Orakel

Die Oracle-Datenbank unterstützt zwei Transaktionsisolationsebenen: READ COMMITTED und SERIALIZABLE.

Die Standard-Transaktionsisolationsebene des Systems ist READ COMMITTED, was bedeutet, dass das Lesen

1. Überprüfen Sie die Standard-Transaktionsisolationsstufe des Systems, die auch die aktuelle Sitzungsisolationsstufe ist

--Erstellen Sie zuerst eine Transaktion

erklären
 trans_id Varchar2(100);
 beginnen
 trans_id := dbms_transaction.local_transaction_id( TRUE );
 Ende;

-- Überprüfen Sie die Transaktionsisolationsstufe

Wählen Sie s.sid, s.serial#,

  CASE BITAND(t.flag, POWER(2, 28))
    WENN 0, DANN ‚LESEN COMMITTED‘
    sonst 'SERIALIZABLE'
  END AS Isolationsstufe
VON v$Transaktion t
JOIN v$session s ON t.addr = s.taddr UND s.sid = sys_context('USERENV', 'SID');

Ergänzung: SQLserver-Sperren und Transaktionsisolationsebenen

Isolationsstufe

Sperren

Gemeinsam genutzte Sperre: Beim gemeinsamen Lesen (Auswählen) dürfen die gesperrten Daten nicht aktualisiert werden, wenn eine Transaktion (eine oder mehrere) mit einer gemeinsam genutzten Sperre für die Daten in der Tabelle vorhanden ist (die Menge der gesperrten Daten hängt von der Granularität der Sperre ab).

Exklusive Sperre: Es kann nur eine geben, und andere Transaktionen können keine gemeinsamen Sperren und keine exklusiven Sperren für die gesperrten Daten erhalten (das heißt, exklusive Sperren sind nicht mit gemeinsamen Sperren kompatibel. Weitere Informationen finden Sie unter Sperrenkompatibilität). Hier legen wir besonderen Wert auf die gesperrten Daten.

Sperren und Isolationsebenen

Typ 1

① READUNCOMMITTED: Es wird keine Sperre ausgegeben

② READCOMMITTED: Geben Sie eine gemeinsame Sperre aus und halten Sie sie aufrecht, bis der Lesevorgang abgeschlossen ist

③ REPEATABLEREAD: Geben Sie eine gemeinsame Sperre aus und halten Sie diese bis zum Ende der Transaktion aufrecht

④ SERIALIZABLE: Gibt eine gemeinsame Sperre aus und hält diese bis zum Ende der Transaktion aufrecht

Typ 2

① NOLOCK: Es wird keine Sperre ausgegeben. Äquivalent zu READUNCOMMITTED

② HOLDLOCK: Geben Sie eine gemeinsame Sperre aus und halten Sie sie bis zum Ende der Transaktion. Äquivalent zu SERIALIZABLE

③ XLOCK: Gibt eine exklusive Sperre aus und hält sie aufrecht, bis die Transaktion beendet ist.

④ UPDLOCK: Gibt eine Aktualisierungssperre aus und hält sie aufrecht, bis die Transaktion beendet ist. (Aktualisierungssperre: blockiert nicht andere Dinge und ermöglicht anderen Dingen das Lesen von Daten (d. h. die Aktualisierungssperre ist mit der gemeinsam genutzten Sperre kompatibel), stellt jedoch sicher, dass die Daten seit dem letzten Lesen nicht aktualisiert wurden.)

⑤ READPAST: Gibt eine gemeinsame Sperre aus, überspringt jedoch das Sperren der Zeile, sie wird nicht blockiert. Anwendbare Bedingungen: Commit-Leselfisolationsebene, Zeilensperren, Select-Anweisung.

Typ 3

① ROWLOCK: Sperre auf Zeilenebene

② PAGLOCK: Sperre auf Seitenebene

③ TABLOCK: Tabellensperre

④ TABLOCKX: Exklusive Tabellensperre

Die Verwendung von XLOCK in einer SELECT-Anweisung verhindert keine Lesevorgänge. Dies liegt daran, dass SQL SERVER über eine spezielle Optimierung auf der Isolationsebene „Read Committed“ verfügt, die prüft, ob die Zeile geändert wurde, und XLOCK ignoriert, wenn sie nicht geändert wurde. Denn dies ist in der Isolationsebene „Read Committed“ tatsächlich akzeptabel.

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden. Sollten dennoch Fehler oder unvollständige Überlegungen vorliegen, freue ich mich über eine Korrektur.