Analyse des MySQL-Sperrmechanismus und der Verwendung

Dieser Artikel veranschaulicht anhand von Beispielen den MySQL-Sperrmechanismus und seine Verwendung. Teilen Sie uns die Einzelheiten zu Ihrer Information mit:

Der Sperrmechanismus von MySQL ist relativ einfach und sein bemerkenswertestes Merkmal ist, dass verschiedene Speicher-Engines unterschiedliche Sperrmechanismen unterstützen. Beispielsweise verwenden die Speicher-Engines MyISAM und MEMORY Sperren auf Tabellenebene; die Speicher-Engine BDB verwendet Seitensperren, unterstützt aber auch Sperren auf Tabellenebene; die Speicher-Engine InnoDB unterstützt sowohl Sperren auf Zeilen- als auch auf Tabellenebene, verwendet aber standardmäßig Sperren auf Zeilenebene.

Die Eigenschaften dieser drei Arten von MySQL-Sperren können grob wie folgt zusammengefasst werden:

(1) Sperre auf Tabellenebene : geringer Overhead, schnelle Sperrung, keine Deadlocks, hohe Sperrgranularität, höchste Wahrscheinlichkeit eines Sperrkonflikts, geringste Parallelität.

(2) Sperre auf Zeilenebene : hoher Overhead, langsame Sperrung; es kann zu Deadlocks kommen; die Sperrgranularität ist am geringsten, die Wahrscheinlichkeit eines Sperrkonflikts am geringsten und die Parallelität am höchsten.

(3) Seitensperre : Der Overhead und die Sperrzeit liegen zwischen der Tabellensperre und der Zeilensperre. Es kann zu Deadlocks kommen. Die Sperrgranularität liegt zwischen der Tabellensperre und der Zeilensperre und die Parallelität ist durchschnittlich.

Rein aus der Perspektive der Sperren eignen sich Sperren auf Tabellenebene eher für abfrageorientierte Anwendungen, die nur eine kleine Datenmenge entsprechend den Indexbedingungen aktualisieren, wie etwa Webanwendungen; Sperren auf Zeilenebene eignen sich dagegen eher für Anwendungen, bei denen eine große Anzahl kleiner Mengen unterschiedlicher Daten entsprechend den Indexbedingungen und gleichzeitigen Abfragen gleichzeitig aktualisiert wird, wie etwa einige Systeme zur Online-Transaktionsverarbeitung.

1. MyISAM-Tabellensperre

1. Sperrkonflikte auf Abfragetabellenebene

Status wie „Tabelle%“ anzeigen;

Wenn der Wert von table_locks_waited hoch ist, bedeutet dies, dass es einen schwerwiegenden Sperrkonflikt auf Tabellenebene gibt.

2. Sperrmodus der MySQL-Sperre auf Tabellenebene

MySQL-Sperren auf Tabellenebene haben zwei Modi: gemeinsame Lesesperre für die Tabelle und exklusive Schreibsperre für die Tabelle.

Wenn eine Sitzung einer Tabelle eine Lesesperre hinzufügt, kann die Sitzung nur auf die gesperrte Tabelle zugreifen und nur Lesevorgänge ausführen. Andere Sitzungen können die Tabelle lesen, aber Schreibvorgänge werden blockiert und müssen auf die Aufhebung der Sperre warten. Wenn eine Sitzung einer Tabelle eine Schreibsperre hinzufügt, kann die Sitzung nur auf die gesperrte Tabelle zugreifen und Lese- und Schreibvorgänge ausführen. Die Lese- und Schreibvorgänge anderer Sitzungen für die Tabelle werden blockiert und müssen warten, bis die Sperre aufgehoben wird.

Die Lese- und Schreibvorgänge von MyISAM-Tabellen sowie die Schreibvorgänge selbst sind seriell.

3. So fügen Sie eine Tabellensperre hinzu

Lesesperre hinzufügen:

Sperrtabelle tbl_name lesen;

Schreibsperre hinzufügen:

Tabelle sperren, Tbl_Name schreiben;

Sperre aufheben:

Tische entsperren;

Vor der Ausführung einer Abfrageanweisung fügt MyISAM automatisch eine Lesesperre für alle beteiligten Tabellen hinzu. Vor der Ausführung einer Aktualisierungsoperation fügt es automatisch eine Schreibsperre für die beteiligten Tabellen hinzu. Dieser Vorgang erfordert kein Eingreifen des Benutzers. Daher müssen Benutzer die MyISAM-Tabelle im Allgemeinen nicht explizit direkt mit dem Befehl LOCK TABLE sperren. Das explizite Sperren einer MyISAM-Tabelle wird im Allgemeinen durchgeführt, um Transaktionsvorgänge bis zu einem gewissen Grad zu simulieren und ein konsistentes Lesen mehrerer Tabellen zu einem bestimmten Zeitpunkt zu erreichen.

Beachten Sie, dass Sie bei der Verwendung von LOCK TABLES nicht nur alle verwendeten Tabellen gleichzeitig sperren müssen, sondern auch dieselbe Tabelle so oft sperren müssen, wie sie in der SQL-Anweisung mit demselben Alias ​​vorkommt. Andernfalls tritt ein Fehler auf!

4. Gleichzeitiges Einfügen

Die MyISAM-Speicher-Engine verfügt über eine Systemvariable concurrent_insert, die speziell zur Steuerung ihres gleichzeitigen Einfügeverhaltens verwendet wird. Ihr Wert kann 0, 1 oder 2 sein.

(1) Wenn concurrent_insert auf 0 gesetzt ist, sind gleichzeitige Einfügungen nicht zulässig.

(2) Wenn concurrent_insert auf 1 gesetzt ist und keine Lücken in der MyISAM-Tabelle vorhanden sind (das heißt, es gibt keine gelöschten Zeilen in der Mitte der Tabelle), erlaubt MyISAM einem Prozess, die Tabelle zu lesen, während ein anderer Prozess Datensätze vom Ende der Tabelle aus einfügt. Dies ist auch die Standardeinstellung für MySQL.

(3) Wenn concurrent_insert auf 2 gesetzt ist, ist das gleichzeitige Einfügen von Datensätzen am Ende der MyISAM-Tabelle zulässig, unabhängig davon, ob die Tabelle Lücken aufweist.

Fügen Sie dem Befehl zum Sperren der Tabelle einfach die Option „local“ hinzu, d. h., sperren Sie die Tabelle tbl_name lokal . Wenn die Bedingungen für gleichzeitiges Einfügen der MyISAM-Tabelle erfüllt sind, können andere Benutzer gleichzeitig Datensätze am Ende der Tabelle einfügen, aber der Aktualisierungsvorgang wird blockiert und der gesperrte Benutzer kann nicht auf die Datensätze zugreifen, die gleichzeitig von anderen Benutzern eingefügt wurden.

5. MyISAM-Sperrplanung

Wenn ein Schreiber und ein Leser gleichzeitig eine Schreibsperre und eine Lesesperre für dieselbe MyISAM-Tabelle anfordern, erhält der Schreiber zuerst die Sperre. Nicht nur das, selbst wenn die Leseanforderung zuerst in der Sperrwarteschlange eintrifft und die Schreibanforderung später eintrifft, wird die Schreibsperre vor der Lesesperrenanforderung eingefügt! Dies liegt daran, dass MySQL Schreibanforderungen im Allgemeinen als wichtiger erachtet als Leseanforderungen. Dies ist auch der Grund, warum MyISAM-Tabellen nicht für Anwendungen mit einer großen Anzahl von Aktualisierungs- und Abfragevorgängen geeignet sind, da eine große Anzahl von Aktualisierungsvorgängen es für Abfragevorgänge schwierig macht, Lesesperren zu erhalten, und daher für immer blockiert werden kann.

Passen Sie das Planungsverhalten von MyISAM durch die folgenden Einstellungen an:

(1) Durch die Angabe des Startparameters low-priority-updates gibt die MyISAM-Engine Lese-Anfragen standardmäßig Priorität.

(2) Durch Ausführen des Befehls SET LOW_PRIORITY_UPDATES=1 wird die Priorität der von der Verbindung gesendeten Aktualisierungsanforderungen verringert.

(3) Verringern Sie die Priorität von INSERT-, UPDATE- oder DELETE-Anweisungen, indem Sie das Attribut LOW_PRIORITY der Anweisung angeben.

(4) Setzen Sie einen geeigneten Wert für den Systemparameter max_write_lock_count . Wenn die Lesesperre einer Tabelle diesen Wert erreicht, senkt MySQL vorübergehend die Priorität der Schreibanforderung, um dem Lesevorgang eine Chance zu geben, die Sperre zu erhalten.

2. InnoDB-Sperrproblem

1. Abfrage InnoDB Zeilensperrenkonflikt

Status wie „innodb_row_lock%“ anzeigen;

Wenn die Werte von InnoDB_row_lock_waits und InnoDB_row_lock_time_avg relativ hoch sind, bedeutet dies, dass der Sperrkonflikt schwerwiegend ist. In diesem Fall können Sie InnoDB-Monitore so einstellen, dass sie die Tabellen und Datenzeilen, in denen Sperrkonflikte auftreten, weiter beobachten und die Ursachen für Sperrkonflikte analysieren.

So öffnen Sie den Monitor:

TABELLE ERSTELLEN innodb_monitor(ein INT) ENGINE=INNODB;
InnoDB-Status anzeigen\G;

So stoppen Sie den Monitor:

Tabelle löschen innodb_monitor;

Nach dem Einschalten des Monitors wird der Überwachungsinhalt standardmäßig alle 15 Sekunden im Protokoll aufgezeichnet. Wenn er längere Zeit eingeschaltet bleibt, wird die .err-Datei sehr groß. Daher muss der Benutzer nach der Bestätigung der Problemursache daran denken, die Überwachungstabelle zu löschen, um den Monitor auszuschalten, oder den Server mit der Option „--console“ starten, um das Schreiben von Protokolldateien zu deaktivieren.

2. InnoDB-Zeilensperre und Sperrmethode

InnoDB verfügt über zwei Arten von Zeilensperren: gemeinsame Sperren (S) und exklusive Sperren (X). Um die Koexistenz von Zeilensperren und Tabellensperren zu ermöglichen und einen Sperrmechanismus mit mehreren Granularitäten zu implementieren, verfügt InnoDB auch über zwei intern verwendete Intention-Sperren: Intention-Shared-Sperren und Intention-Exklusiv-Sperren. Beide Intention-Sperren sind Tabellensperren. Eine Transaktion muss zunächst die Absichtssperre für die entsprechende Tabelle erhalten, bevor sie eine Datenzeile sperren kann.

Absichtssperren werden von InnoDB automatisch und ohne Benutzereingriff hinzugefügt. Bei UPDATE-, DELETE- und INSERT-Anweisungen fügt InnoDB dem betreffenden Datensatz automatisch eine exklusive Sperre (X) hinzu. Bei normalen SELECT-Anweisungen fügt InnoDB keine Sperren hinzu. Transaktionen können durch die folgenden Anweisungen dem Datensatz explizit gemeinsame Sperren oder exklusive Sperren hinzufügen.

Setzen Sie Autocommit = 0.

Gemeinsam genutzte(s) Schloss(e):

SELECT * FROM table_name WHERE ... LOCK IM FREIGABEMODUS

Exklusive Sperre (X):

SELECT * FROM Tabellenname WHERE ... FOR UPDATE

Sperre aufheben:

Tische entsperren;

(Die Transaktion wird implizit festgeschrieben)

Wenn eine Transaktion eine gemeinsame Sperre für eine Tabelle erhält, können andere Transaktionen Datensätze in der Tabelle abfragen und den Datensätzen ebenfalls gemeinsame Sperren hinzufügen. Wenn eine Transaktion eine Tabelle aktualisiert und eine andere Transaktion ebenfalls eine gemeinsame Sperre für die Tabelle hinzugefügt hat, muss sie warten, bis die Sperre freigegeben wird. Wenn die andere Transaktion die Tabelle gleichzeitig aktualisiert, führt dies zu einem Deadlock, die andere Transaktion wird beendet und die aktuelle Transaktion schließt den Aktualisierungsvorgang ab. Wenn eine Transaktion eine exklusive Sperre für eine Tabelle erhält, können andere Transaktionen nur die Datensätze der Tabelle abfragen, aber keine gemeinsamen Sperren hinzufügen oder Datensätze aktualisieren und es kommt zu Wartezeiten.

3. Implementierungsmethode für InnoDB-Zeilensperren

InnoDB-Zeilensperren werden implementiert, indem die Indexelemente im Index gesperrt werden. Diese Funktion zur Implementierung von Zeilensperren in InnoDB bedeutet:

(1) InnoDB verwendet Zeilensperren nur beim Abrufen von Daten über Indexbedingungen. Andernfalls verwendet InnoDB Tabellensperren.

(2) Da MySQL-Zeilensperren auf Indizes und nicht auf Datensätze verweisen, kommt es beim Zugriff auf Datensätze in unterschiedlichen Zeilen mit dem gleichen Indexschlüssel zu Sperrkonflikten.

(3) Wenn eine Tabelle mehrere Indizes hat, können verschiedene Transaktionen unterschiedliche Indizes verwenden, um unterschiedliche Zeilen zu sperren. Darüber hinaus verwendet InnoDB Zeilensperren, um die Daten zu sperren, unabhängig davon, ob ein Primärschlüsselindex, ein eindeutiger Index oder ein normaler Index verwendet wird. (Obwohl ein anderer Index verwendet wird, müssen Sie trotzdem warten, wenn der Datensatz durch eine andere Sitzung gesperrt wurde.)

(4) Auch wenn in der Bedingung ein Indexfeld verwendet wird, wird MySQL anhand der Kosten verschiedener Ausführungspläne entscheiden, ob der Index zum Abrufen von Daten verwendet wird. Wenn MySQL der Ansicht ist, dass ein vollständiger Tabellenscan effizienter ist, beispielsweise bei einigen sehr kleinen Tabellen, wird der Index nicht verwendet. In diesem Fall verwendet InnoDB eine Tabellensperre anstelle einer Zeilensperre.

4. Lückensperre

Wenn Sie zum Abrufen von Daten Bereichsbedingungen verwenden, sperrt InnoDB auch Datensätze, deren Schlüsselwerte innerhalb des Bedingungsbereichs liegen, aber nicht vorhanden sind. Diese Sperre wird als „Lückensperre“ bezeichnet. InnoDB verwendet Gap Locks, um Phantomlesevorgänge zu verhindern und die Anforderungen der Wiederherstellung und Replikation zu erfüllen. Dieser Sperrmechanismus blockiert jedoch das gleichzeitige Einfügen von Schlüsselwerten innerhalb des qualifizierenden Bereichs und verursacht dadurch erhebliche Wartezeiten bei der Sperre. Sie sollten daher versuchen, die Verwendung von Bereichsbedingungen zum Abrufen von Daten zu vermeiden.

Zusätzlich zur Verwendung von Lückensperren beim Sperren durch Bereichsbedingungen verwendet InnoDB auch Lückensperren, wenn eine Gleichheitsbedingung verwendet wird, um eine Sperre für einen nicht vorhandenen Datensatz anzufordern!

5. Auswirkungen von Wiederherstellungs- und Replikationsanforderungen auf den InnoDB-Sperrmechanismus

MySQL verwendet BINLOG, um erfolgreiche INSERT-, UPDATE-, DELETE- und andere SQL-Anweisungen aufzuzeichnen, die Daten aktualisieren, und realisiert so die Wiederherstellung und Master-Slave-Replikation der MySQL-Datenbank. Der MySQL-Wiederherstellungsmechanismus (Replikation ist eigentlich eine kontinuierliche Wiederherstellung basierend auf BINLOG im Slave-MySQL) weist die folgenden Eigenschaften auf:

(1) Die MySQL-Wiederherstellung erfolgt auf der Ebene der SQL-Anweisungen, d. h. die SQL-Anweisungen werden im BINLOG erneut ausgeführt.

(2) Das Binlog von MySQL zeichnet die Transaktionen in der Reihenfolge auf, in der sie übermittelt werden, und die Wiederherstellung wird auch in dieser Reihenfolge durchgeführt.

Daher lauten die Wiederherstellungs- und Replikationsanforderungen von MySQL für den Sperrmechanismus: Bevor eine Transaktion festgeschrieben wird, können andere gleichzeitige Transaktionen keine Datensätze einfügen, die ihre Sperrbedingungen erfüllen, d. h. Phantomlesevorgänge sind nicht zulässig.

Darüber hinaus verwendet MySQL für allgemeine Select-Anweisungen Daten mehrerer Versionen, um Konsistenz zu erreichen, und erfordert keine Sperren. Bei SQL-Anweisungen wie „ insert into target_tab select * from source_tab where ... “ und „ create table new_tab ...select ... From source_tab where ... “ hat der Benutzer jedoch keine Aktualisierungen an source_tab vorgenommen, aber MySQL hat für solche SQL-Anweisungen eine spezielle Verarbeitung durchgeführt und source_tab eine gemeinsame Sperre hinzugefügt. Dies liegt daran, dass, wenn die Sperre nicht hinzugefügt wird und eine andere Transaktion während der Ausführung dieser SQL-Anweisung zuerst source_tab aktualisiert und festschreibt, der Aktualisierungsvorgang im BINLOG vor der SQL-Anweisung liegt. Wenn dieses BINLOG zum Wiederherstellen der Datenbank verwendet wird, entspricht das Wiederherstellungsergebnis nicht der tatsächlichen Anwendungslogik und die Replikation führt zu Inkonsistenzen zwischen der Master- und der Slave-Datenbank. Dies liegt daran, dass die tatsächlich in target_tab oder new_tab eingefügten Daten die Daten sind, bevor source_tab durch eine andere Transaktion aktualisiert wurde, BINLOG jedoch die Daten vor der Aktualisierung und anschließenden Ausführung der select...insert...-Anweisung aufzeichnet. Wenn es sich bei dem SELECT in der obigen Anweisung um eine Bereichsbedingung handelt, fügt InnoDB der Quelltabelle auch eine Lückensperre hinzu. Daher blockiert diese Art von SQL-Anweisung gleichzeitige Aktualisierungen der Originaltabelle und sollte so weit wie möglich vermieden werden.

6. Situationen und Vorsichtsmaßnahmen bei der Verwendung von InnoDB-Tabellensperren

Für InnoDB-Tabellen sollten in den meisten Fällen Sperren auf Zeilenebene verwendet werden. Bei einigen speziellen Transaktionen können jedoch auch Sperren auf Tabellenebene in Betracht gezogen werden, hauptsächlich in den folgenden zwei Situationen:

(1) Die Transaktion muss die meisten oder alle Daten aktualisieren und die Tabelle ist relativ groß. Wenn die standardmäßige Zeilensperre verwendet wird, ist nicht nur die Effizienz der Transaktionsausführung gering, sondern es kann auch dazu führen, dass andere Transaktionen lange warten müssen und es zu Sperrkonflikten kommt. In diesem Fall können Sie die Verwendung einer Tabellensperre in Betracht ziehen, um die Ausführungsgeschwindigkeit der Transaktion zu erhöhen.

(2) Die Transaktion umfasst mehrere Tabellen und ist relativ komplex. Sie kann zu Deadlocks führen und eine große Anzahl von Transaktions-Rollbacks zur Folge haben. In diesem Fall können Sie auch in Erwägung ziehen, alle an der Transaktion beteiligten Tabellen gleichzeitig zu sperren, um Deadlocks zu vermeiden und den durch das Zurücksetzen der Transaktion verursachten Datenbank-Overhead zu verringern.

Darüber hinaus müssen Sie bei der Verwendung von Tabellensperren in InnoDB die folgenden zwei Punkte beachten:

(1) Obwohl LOCK TABLES verwendet werden kann, um InnoDB Sperren auf Tabellenebene hinzuzufügen, werden Tabellensperren nicht von der Speicher-Engine-Schicht von InnoDB verwaltet, sondern von deren oberer Schicht, MySQL Server. Nur wenn autocommit=0 und innodb_table_locks=1 (Standardeinstellungen) sind, kann die InnoDB-Schicht die von MySQL hinzugefügten Tabellensperren erkennen, und MySQL Server kann auch die von InnoDB hinzugefügten Zeilensperren erkennen. In diesem Fall kann InnoDB Deadlocks, die Sperren auf Tabellenebene betreffen, automatisch erkennen; andernfalls kann InnoDB solche Deadlocks nicht automatisch erkennen und behandeln.

(2) Wenn Sie LOCK TABLES verwenden, um eine InnoDB-Tabelle zu sperren, achten Sie darauf, AUTOCOMMIT auf 0 zu setzen, da MySQL die Tabelle sonst nicht sperrt. Verwenden Sie UNLOCK TABLES nicht, um die Tabellensperre freizugeben, bevor die Transaktion beendet ist, da UNLOCK TABLES die Transaktion implizit festschreibt. COMMIT oder ROLLBACK können die von LOCK TABLES hinzugefügte Sperre auf Tabellenebene nicht freigeben. UNLOCK TABLES muss verwendet werden, um die Tabellensperre freizugeben.

7. Über Deadlocks

MyISAM-Tabellensperren sind frei von Deadlocks , da MyISAM immer alle benötigten Sperren auf einmal erhält und diese entweder alle erfüllt oder wartet, so dass es zu keinem Deadlock kommt. Aber in InnoDB werden Sperren, mit Ausnahme von Transaktionen, die aus einer einzelnen SQL-Anweisung bestehen, schrittweise erworben, wodurch es in InnoDB zu Deadlocks kommen kann.

Wenn ein Deadlock auftritt, kann InnoDB ihn im Allgemeinen automatisch erkennen und eine Transaktion dazu veranlassen, die Sperre freizugeben und ein Rollback durchzuführen, während die andere Transaktion die Sperre erwirbt und mit der Ausführung der Transaktion fortfährt. Wenn jedoch externe Sperren oder Tabellensperren beteiligt sind, kann InnoDB Deadlocks nicht automatisch erkennen. Dies muss durch Festlegen des Parameters für das Wartezeittimeout für Sperren innodb_lock_wait_timeout gelöst werden.

Im Allgemeinen sind Deadlocks ein Problem des Anwendungsdesigns. Die meisten Deadlocks können durch Anpassung der Geschäftsprozesse, des Datenbankobjektdesigns, der Transaktionsgröße und der SQL-Anweisungen für den Zugriff auf die Datenbank vermieden werden. Nachfolgend sind anhand von Beispielen einige gängige Methoden zur Vermeidung von Deadlocks aufgeführt.

(1) Wenn in einer Anwendung verschiedene Programme gleichzeitig auf mehrere Tabellen zugreifen, sollten Sie versuchen, den Zugriff auf die Tabellen in derselben Reihenfolge zu vereinbaren. Dadurch kann die Wahrscheinlichkeit eines Deadlocks erheblich verringert werden.

(2) Wenn das Programm Daten stapelweise verarbeitet und die Daten im Voraus sortiert werden, um sicherzustellen, dass jeder Thread die Datensätze in einer festen Reihenfolge verarbeitet, kann die Möglichkeit eines Deadlocks erheblich verringert werden.

(3) Wenn Sie in einer Transaktion einen Datensatz aktualisieren möchten, sollten Sie direkt eine Sperre mit ausreichendem Level beantragen, also eine exklusive Sperre, anstatt zuerst eine gemeinsame Sperre zu beantragen und dann beim Aktualisieren eine exklusive Sperre zu beantragen. Denn wenn ein Benutzer eine exklusive Sperre beantragt, haben andere Transaktionen möglicherweise bereits eine gemeinsame Sperre für denselben Datensatz erhalten, was zu einem Sperrenkonflikt oder sogar einem Deadlock führt.

(4) Wenn auf der Isolationsebene REPEATABLE-READ zwei Threads gleichzeitig mit SELECT...FOR UPDATE eine exklusive Sperre für denselben Bedingungsdatensatz hinzufügen, sperren beide Threads den Datensatz erfolgreich, wenn es keinen Datensatz gibt, der die Bedingung erfüllt. Das Programm stellt fest, dass der Datensatz noch nicht vorhanden ist, und versucht daher, einen neuen Datensatz einzufügen. Wenn zwei Threads dies tun, kommt es zu einem Deadlock. In diesem Fall kann das Problem durch Ändern der Isolationsebene auf READ COMMITTED vermieden werden.

(5) Wenn die Isolationsebene READ COMMITTED ist, müssen beide Threads zunächst SELECT...FOR UPDATE ausführen, um zu ermitteln, ob Datensätze vorhanden sind, die die Bedingungen erfüllen. Wenn nicht, werden die Datensätze eingefügt. Zu diesem Zeitpunkt kann nur ein Thread erfolgreich einfügen, und der andere Thread wartet auf die Sperre. Wenn der erste Thread übermittelt, macht der zweite Thread aufgrund des Primärschlüssels einen Fehler, aber obwohl dieser Thread einen Fehler macht, erhält er eine exklusive Sperre! Wenn zu diesem Zeitpunkt ein dritter Thread erneut eine exklusive Sperre beantragt, tritt ein Deadlock auf. In diesem Fall können Sie den Einfügevorgang direkt ausführen und dann die Ausnahme bezüglich der Duplizierung des Primärschlüssels abfangen. Wenn ein Fehler bezüglich der Duplizierung des Primärschlüssels auftritt, führen Sie immer ROLLBACK aus, um die erworbene exklusive Sperre freizugeben.

Leser, die an weiteren MySQL-bezogenen Inhalten interessiert sind, können sich die folgenden Themen ansehen: „Zusammenfassung der Kenntnisse im Zusammenhang mit MySQL-Datenbanksperren“, „Zusammenfassung der Kenntnisse im Zusammenhang mit MySQL-gespeicherten Prozeduren“, „Zusammenfassung der allgemeinen MySQL-Funktionen“, „Zusammenfassung der Kenntnisse im Zusammenhang mit MySQL-Protokollvorgängen“ und „Zusammenfassung der Kenntnisse im Zusammenhang mit MySQL-Transaktionsvorgängen“.

Ich hoffe, dass dieser Artikel für jedermann beim Entwurf einer MySQL-Datenbank hilfreich ist.