Die Beziehung zwischen MySQL-Sperren, Transaktionsisolationsstufen und Anwendungen

MySQL-Sperrtransaktionsisolationsstufe und -anwendung
In der Datenbank ist die Transaktionsisolationsstufe ein sehr wichtiges Konzept, das den Grad der Isolation zwischen gleichzeitigen Transaktionen bestimmt. MySQL bietet vier Transaktionsisolationsstufen: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ und SERIALIZABLE. Verschiedene Transaktionsisolationsstufen verfügen über unterschiedliche Sperrstrategien für das Lesen und Schreiben von Daten. Daher ist es wichtig, die richtige Transaktionsisolationsstufe in Ihrer Anwendung richtig auszuwählen und zu verwenden.

1. UNBEKANNT LESEN: Auf dieser Ebene können Transaktionen nicht festgeschriebene Daten von anderen Transaktionen lesen. Dies bedeutet, dass es zu einem Dirty Read kommen kann, d. h. es werden ungeprüfte Daten gelesen. Diese Stufe wird im Allgemeinen nicht empfohlen, es sei denn, Sie müssen unter besonderen Umständen Echtzeitdaten erhalten.
2. READ COMMITTED: Auf dieser Ebene können Transaktionen nur übermittelte Daten lesen. Dies vermeidet Dirty-Read-Probleme, kann jedoch zu nicht wiederholbaren Leseproblemen führen. Beim nicht wiederholbaren Lesen werden dieselben Daten zweimal in derselben Transaktion gelesen, die Ergebnisse sind jedoch inkonsistent. Dies liegt daran, dass andere Transaktionen die Daten möglicherweise während der Transaktionsausführung aktualisiert haben.
3. WIEDERHOLBARES LESEN: Auf dieser Ebene kann eine Transaktion dieselben Daten mehrmals mit konsistenten Ergebnissen lesen. Dies wird dadurch erreicht, dass die Daten während des Lesevorgangs gesperrt werden. Auf der Ebene REPEATABLE READ teilt der Lesevorgang die Sperre für die Datenzeilen, die die Bedingungen erfüllen, sodass andere Transaktionen die Daten nur lesen, aber nicht ändern können. Es kann jedoch weiterhin zu Phantomleseproblemen kommen. Beim Phantomlesen werden Daten in einem Bereich zweimal in derselben Transaktion gelesen, die Ergebnisse sind jedoch inkonsistent. Dies liegt daran, dass während der Transaktionsausführung möglicherweise andere Transaktionen Daten eingefügt oder gelöscht haben, die die Bedingungen erfüllen.
4. SERIALISIERBAR: Auf dieser Ebene werden Transaktionen seriell ausgeführt. Dies bedeutet, dass nur eine Transaktion die Daten gleichzeitig ändern kann und andere Transaktionen auf die Freigabe der Sperre warten. Auf dieser Ebene können die Probleme von Dirty Reads, nicht wiederholbaren Lesevorgängen und Phantom Reads vollständig vermieden werden, sie hat jedoch auch erhebliche Auswirkungen auf die Parallelitätsleistung, da Sie warten müssen, bis andere Transaktionen die Sperre aufheben. 🔜

CREATE TABLE test_table (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  age INT
);

Nach dem Login kopieren

-- 执行事务1
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
START TRANSACTION;
SELECT * FROM test_table WHERE id = 1;

-- 执行事务2
START TRANSACTION;
UPDATE test_table SET age = 20 WHERE id = 1;
COMMIT;

-- 继续执行事务1
SELECT * FROM test_table WHERE id = 1;
COMMIT;

1. WIEDERHOLBARES LESEN:

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Nach dem Login kopieren
   In diesem Beispiel fügt Transaktion 1 beim Lesen von Daten eine gemeinsame Sperre hinzu und Transaktion 2 wartet darauf, dass Transaktion 1 die gemeinsame Sperre aufhebt, bevor sie ausgeführt werden kann.

2. SERIALISIERBAR:

   -- 执行事务1
   SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
   START TRANSACTION;
   SELECT * FROM test_table WHERE id = 1;
   
   -- 执行事务2
   START TRANSACTION;
   UPDATE test_table SET age = 20 WHERE id = 1;
   COMMIT;
   
   -- 继续执行事务1
   SELECT * FROM test_table WHERE id = 1;
   COMMIT;

   Nach dem Login kopieren
   In diesem Beispiel fügt Transaktion 1 beim Lesen von Daten eine gemeinsame Sperre hinzu und Transaktion 2 wartet darauf, dass Transaktion 1 die gemeinsame Sperre aufhebt, bevor sie ausgeführt werden kann.

3. Anhand der obigen Codebeispiele können wir sehen, wie die Sperrstrategie unter verschiedenen Transaktionsisolationsstufen funktioniert. Bei der tatsächlichen Anwendungsentwicklung ist es sehr wichtig, die geeignete Transaktionsisolationsstufe auszuwählen, die entsprechend den spezifischen Geschäftsszenarien und Leistungsanforderungen ausgewählt werden kann.

Das obige ist der detaillierte Inhalt vonDie Beziehung zwischen MySQL-Sperren, Transaktionsisolationsstufen und Anwendungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!