Zusammenfassung der MySQL InnoDB-Sperren

1. Gemeinsam genutzte und exklusive Sperren

gemeinsame Sperre

Exklusive Sperre

InnoDB implementiert standardmäßige Sperren auf Zeilenebene, die zwei Arten von Sperren umfassen: gemeinsame Sperren und exklusive Sperren.

Eine gemeinsame Sperre (S) ermöglicht der Transaktion, die die Sperre hält, das Lesen einer Zeile.

Eine exklusive (X) Sperre ermöglicht der Transaktion, die die Sperre hält, das Aktualisieren oder Löschen einer Zeile.

Eine gemeinsam genutzte Sperre ermöglicht der Transaktion, die die Sperre hält, das Lesen einer Zeile.

Eine exklusive Sperre ermöglicht der Transaktion, die die Sperre hält, die Zeile zu aktualisieren oder zu löschen.

Wenn die Transaktion T1 eine gemeinsame Sperre (S) für Zeile r hält, wird eine Anforderung einer anderen Transaktion T2 wie folgt verarbeitet:

• Die Anforderung von T2 für das S-Schloss kann sofort gewährt werden. Als Ergebnis halten sowohl T1 als auch T2 eine S-Sperre für Zeile r.
• Die Anforderung von T2 für die X-Sperre kann nicht sofort gewährt werden.

Wenn die Transaktion T1 eine exklusive Sperre (X) für Zeile r hält, kann einer Anforderung einer anderen Transaktion T2 nicht sofort eine der beiden Sperrarten für r gewährt werden. Stattdessen muss Transaktion T2 warten, bis Transaktion T1 ihre Sperre für Zeile r freigibt.

2. Absichtssperren

Absichtssperren

InnoDB unterstützt Sperren mit mehreren Granularitäten, sodass Zeilensperren und Tabellensperren nebeneinander bestehen können. Beispielsweise erstellt eine Anweisung wie LOCK TABLES ... WRITE eine exklusive Sperre (X-Sperre) für die angegebene Tabelle. Um Sperren auf mehreren Granularitätsebenen zu implementieren, verwendet InnoDB Intention-Locks. Eine Absichtssperre ist eine Sperre auf Tabellenebene, die einer Transaktion angibt, welchen Sperrtyp (gemeinsam oder exklusiv) sie später für eine Zeile in einer Tabelle verwenden muss.

Es gibt zwei Arten von Absichtssperren:

• Eine beabsichtigte gemeinsame Sperre (IS) gibt an, dass eine Transaktion beabsichtigt, eine gemeinsame Sperre für eine einzelne Zeile in einer Tabelle festzulegen.
• Eine beabsichtigte exklusive Sperre (IX) gibt an, dass eine Transaktion beabsichtigt, eine exklusive Sperre für eine einzelne Zeile in einer Tabelle festzulegen.
  

Beispielsweise setzt SELECT ... LOCK IN SHARE MODE eine IS-Sperre und SELECT ... FOR UPDATE setzt eine IX-Sperre.

Die Vereinbarung der Absichtssperre lautet wie folgt:

Bevor eine Transaktion eine gemeinsame Sperre für eine Zeile in einer Tabelle erhalten kann, muss sie zunächst eine IS-Sperre oder eine stärkere Sperre für die Tabelle erhalten.
Bevor eine Transaktion eine exklusive Sperre für eine Zeile in einer Tabelle erhält, muss sie zunächst eine IX-Sperre für die Tabelle erhalten.
Die Kompatibilität der Sperrtypen auf Tabellenebene ist wie folgt:

Der anfordernden Transaktion wird eine Sperre gewährt, wenn sie mit einer vorhandenen Sperre kompatibel ist. Sie wird jedoch nicht gewährt, wenn sie mit einer vorhandenen Sperre in Konflikt steht. Die Transaktion wartet, bis die bestehende Sperre, die den Konflikt verursacht, aufgehoben wird. Wenn eine Sperranforderung mit einer vorhandenen Sperre in Konflikt steht und nicht gewährt werden kann, da dies zu einem Deadlock führen würde, tritt ein Fehler auf.

Absichtssperren blockieren nichts außer Anforderungen für die gesamte Tabelle (wie etwa LOCK TABLES ... WRITE). Der Hauptzweck einer Absichtssperre besteht darin, anzuzeigen, dass jemand eine Zeile in einer Tabelle sperrt oder sperren möchte.

3. Datensatzsperren

Datensatzsperren

Eine Datensatzsperre ist eine Sperre für einen Indexdatensatz.

Eine Datensatzsperre ist eine Sperre für einen Indexdatensatz. Beispielsweise verhindert SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE;, dass andere Transaktionen Zeilen einfügen, aktualisieren oder löschen, bei denen der Wert von t.c1 10 ist.

Datensatzsperren sperren immer Indexdatensätze, auch wenn für eine Tabelle keine Indizes definiert sind. Wenn die Tabelle keine Indizes hat, erstellt InnoDB einen versteckten gruppierten Index und verwendet diesen Index zum Sperren des Datensatzes.

4. Lückenschlösser

Lückenschlösser

Eine Lückensperre ist eine Sperre für eine Lücke zwischen Indexdatensätzen oder eine Sperre für die Lücke vor dem ersten oder nach dem letzten Indexdatensatz.

Eine Lückensperre ist eine Sperre für die Lücke zwischen Indexdatensätzen oder eine Sperre für die Lücke vor dem ersten Indexdatensatz oder nach dem letzten Indexdatensatz.

Beispielsweise verhindert SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;, dass andere Transaktionen den Wert 15 in die Spalte t.c1 einfügen, unabhängig davon, ob die Spalte bereits einen solchen Wert enthält, da die Lücken zwischen allen im Bereich vorhandenen Werten gesperrt sind.

Eine Lücke kann sich über einen einzelnen Indexwert oder mehrere Indexwerte erstrecken oder sogar leer sein.

Gap-Locks sind Teil des Kompromisses zwischen Leistung und Parallelität und werden in einigen Transaktionsisolationsebenen verwendet, in anderen jedoch nicht.

Bei Anweisungen, die einen eindeutigen Index zum Sperren von Zeilen verwenden, um nach einer eindeutigen Zeile zu suchen, ist die Lückensperre nicht erforderlich.

Wenn die Spalte „id“ beispielsweise einen eindeutigen Index besitzt, übernimmt die folgende Anweisung eine Index-Datensatzsperre nur für die Zeile mit dem ID-Wert 100, unabhängig davon, ob andere Sitzungen Zeilen in die vorhergehende Lücke einfügen:

Wählen Sie * aus Kind, wobei ID = 100 ist.

Wenn die ID-Spalte keinen oder einen nicht eindeutigen Index besitzt, sperrt die Anweisung die führende Lücke.

Hier ist auch zu beachten, dass verschiedene Transaktionen widersprüchliche Sperren für eine Lücke halten können.

Beispielsweise kann Transaktion A eine gemeinsame Lückensperre (Lücken-S-Sperre) auf einer Lücke halten, während Transaktion B eine exklusive Lückensperre (Lücken-X-Sperre) auf derselben Lücke hält. Der Grund für das Zulassen widersprüchlicher Lückensperren liegt darin, dass beim Löschen eines Datensatzes aus einem Index die von verschiedenen Transaktionen gehaltenen Lückensperren für den Datensatz zusammengeführt werden müssen.

Der einzige Zweck von Lückensperren in InnoDB besteht darin, das Einfügen anderer Transaktionen in die Lücke zu verhindern. Lückensperren können koexistieren. Eine von einer Transaktion erworbene Lückensperre verhindert nicht, dass eine andere Transaktion eine Lückensperre für dieselbe Lücke erwirbt. Es wird nicht zwischen gemeinsamen und exklusiven Intervallsperren unterschieden. Sie stehen nicht im Konflikt miteinander und erfüllen die gleiche Funktion.

5. Schlösser mit nächstem Schlüssel

Eine Next-Key-Sperre ist eine Kombination aus einer Datensatzsperre für den Indexdatensatz und einer Lückensperre für die Lücke vor dem Indexdatensatz.

Eine Next-Key-Sperre ist eine Kombination aus einer Datensatzsperre auf dem Indexdatensatz und einer Lückensperre vor dem Indexdatensatz.

InnoDB führt die Sperrung auf Zeilenebene folgendermaßen durch: Beim Durchsuchen oder Scannen eines Tabellenindex setzt es gemeinsame oder exklusive Sperren für die Indexdatensätze, auf die es stößt. Daher sind Sperren auf Zeilenebene eigentlich Indexdatensatzsperren. Eine Next-Key-Sperre eines Indexdatensatzes wirkt sich auch auf die „Lücke“ vor diesem Indexdatensatz aus. Das heißt, die Nächste-Schlüssel-Sperre ist die Indexdatensatzsperre plus die Lückensperre vor dem Indexdatensatz. Wenn eine Sitzung eine gemeinsame oder exklusive Sperre für einen Datensatz R in einem Index hat, kann eine andere Sitzung keinen neuen Indexdatensatz in die Lücke vor R in der Indexreihenfolge einfügen.

Angenommen, ein Index enthält die Werte 10, 11, 13 und 20. Die möglichen Next-Key-Sperren für diesen Index decken die folgenden Bereiche ab:

(negative Unendlichkeit, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positiv unendlich)

Standardmäßig verwendet InnoDB die Transaktionsisolationsebene REPEATABLE READ. In diesem Fall verwendet InnoDB Next-Key-Sperren für Suchvorgänge und Index-Scans, um Phantomzeilen zu verhindern.

6. Absichtssperren einfügen

Absichtssperren einfügen

Eine Einfügesperre ist eine Lückensperre, die durch einen INSERT-Vorgang gesetzt wird, bevor eine Zeile eingefügt wird. Diese Sperre bedeutet, dass mehrere Transaktionen, die in dieselbe Indexlücke eingefügt werden, nicht aufeinander warten müssen, sofern sie nicht an derselben Position in der Lücke eingefügt werden. Angenommen, es gibt Indexdatensätze mit den Werten 4 und 7. Separate Transaktionen versuchen, die Werte 5 und 6 einzufügen. Jede Transaktion sperrt die Lücke zwischen 4 und 7 mit einer Einfügeabsichtssperre, bevor sie eine exklusive Sperre für die eingefügte Zeile erhält, blockiert sich jedoch nicht gegenseitig, da die Zeilen nicht in Konflikt stehen.

7. AUTO-INC-Schlösser

Eine AUTO-INC-Sperre ist eine spezielle Sperre auf Tabellenebene, die durch Transaktionen erworben wird, die in eine Tabelle mit einer AUTO_INCREMENT-Spalte einfügen. Im einfachsten Fall, wenn eine Transaktion Werte in eine Tabelle einfügt, müssen alle anderen Transaktionen auf ihre eigenen Einfügungen in diese Tabelle warten, damit die von der ersten Transaktion eingefügten Zeilen aufeinanderfolgende Primärschlüsselwerte erhalten.

https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html

Oben finden Sie eine detaillierte Zusammenfassung der MySQL InnoDB-Sperre. Weitere Informationen zur MySQL InnoDB-Sperre finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!