Ursachen und Lösungen für MySQL-Deadlocks

Die Datenbank ist wie das Betriebssystem eine gemeinsam genutzte Ressource, die von mehreren Benutzern verwendet wird. Wenn mehrere Benutzer gleichzeitig auf Daten zugreifen, werden in der Datenbank mehrere Transaktionen generiert, um gleichzeitig auf dieselben Daten zuzugreifen. Wenn gleichzeitige Vorgänge nicht kontrolliert werden, können falsche Daten gelesen und gespeichert werden, wodurch die Konsistenz der Datenbank zerstört wird. Sperren sind eine sehr wichtige Technologie zur Implementierung der Datenbank-Parallelitätskontrolle. In tatsächlichen Anwendungen treten häufig sperrenbezogene Ausnahmen auf. Wenn zwei Transaktionen einen Satz widersprüchlicher Sperren erfordern und die Transaktionen nicht fortgesetzt werden können, tritt ein Deadlock auf, der die normale Ausführung der Anwendung ernsthaft beeinträchtigt.

Es gibt zwei grundlegende Arten von Sperren in der Datenbank: exklusive Sperren (Exclusive Locks, d. h. X-Sperren) und gemeinsam genutzte Sperren (Share Locks, d. h. S-Sperren). Wenn ein Datenobjekt exklusiv gesperrt ist, können andere Transaktionen es weder lesen noch ändern. Datenobjekte mit gemeinsam genutzten Sperren können von anderen Transaktionen gelesen, aber nicht geändert werden. Die Datenbank verwendet diese beiden grundlegenden Sperrtypen, um die Parallelität von Datenbanktransaktionen zu steuern.

Der erste Fall einer Sackgasse

Ein Benutzer A greift auf Tabelle A zu (sperrt Tabelle A) und greift dann auf Tabelle B zu; ein anderer Benutzer B greift auf Tabelle B zu (sperrt Tabelle B) und versucht dann, auf Tabelle A zuzugreifen; da Benutzer B zu diesem Zeitpunkt Tabelle B gesperrt hat, muss Benutzer A warten, bis Benutzer B Tabelle B freigibt, bevor er fortfahren kann. Ebenso muss Benutzer B warten, bis Benutzer A Tabelle A freigibt, bevor er fortfahren kann. Dies ist ein Deadlock.

Lösung:

Diese Art von Deadlock kommt recht häufig vor und wird durch einen Programmfehler verursacht. Es gibt keine andere Möglichkeit, ihn zu beheben, als die Programmlogik anzupassen. Analysieren Sie die Logik des Programms sorgfältig. Wenn Sie mehrere Tabellen in der Datenbank bearbeiten, versuchen Sie, sie in derselben Reihenfolge zu verarbeiten, und vermeiden Sie, dass zwei Ressourcen gleichzeitig gesperrt werden. Wenn Sie beispielsweise die Tabellen A und B bearbeiten, verarbeiten Sie sie immer in der Reihenfolge „erst A, dann B“. Wenn zwei Ressourcen gleichzeitig gesperrt werden müssen, stellen Sie sicher, dass die Ressourcen immer in derselben Reihenfolge gesperrt werden.

Die zweite Deadlock-Situation

Benutzer A fragt einen Datensatz ab und ändert ihn dann; dann ändert Benutzer B den Datensatz. Die Art der Sperre in der Transaktion von Benutzer A wird vom gemeinsamen Sperrversuch der Abfrage zu einer exklusiven Sperre hochgestuft. Da Benutzer B jedoch eine gemeinsame Sperre hat, muss die exklusive Sperre von Benutzer B warten, bis A die gemeinsame Sperre freigibt. Da A seine exklusive Sperre aufgrund der exklusiven Sperre von B nicht hochstufen kann, kann es auch die gemeinsame Sperre nicht freigeben, sodass ein Deadlock auftritt. Dieser Deadlock ist subtiler, tritt aber häufig bei größeren Projekten auf. Beispielsweise wird in einem bestimmten Projekt nach dem Klicken auf eine Schaltfläche auf einer Seite die Schaltfläche nicht sofort ungültig, was dazu führt, dass der Benutzer schnell mehrmals auf dieselbe Schaltfläche klickt. Auf diese Weise führt derselbe Codeabschnitt mehrere Vorgänge für denselben Datensatz in der Datenbank aus, was leicht zu einem Deadlock führen kann.

Lösung:

1. Machen Sie Steuerelemente wie Schaltflächen sofort nach dem Anklicken ungültig, um zu verhindern, dass Benutzer wiederholt darauf klicken, und um zu vermeiden, dass gleichzeitig am selben Datensatz gearbeitet wird.

2. Verwenden Sie zur Steuerung optimistisches Sperren. Optimistisches Sperren wird meist basierend auf dem Mechanismus zur Aufzeichnung der Datenversion implementiert. Das heißt, fügen Sie den Daten eine Versionskennung hinzu. In einer Versionslösung, die auf einer Datenbanktabelle basiert, wird dies im Allgemeinen dadurch erreicht, dass der Datenbanktabelle ein Feld „Version“ hinzugefügt wird. Beim Einlesen von Daten wird die Versionsnummer mit ausgelesen, bei einem späteren Update wird die Versionsnummer um eins erhöht. Zu diesem Zeitpunkt werden die Versionsdaten der übermittelten Daten mit den aktuellen Versionsinformationen des entsprechenden Datensatzes in der Datenbanktabelle verglichen. Wenn die Versionsnummer der übermittelten Daten größer als die aktuelle Versionsnummer der Datenbanktabelle ist, werden sie aktualisiert, andernfalls gelten sie als abgelaufene Daten. Der optimistische Sperrmechanismus vermeidet den Datenbanksperr-Overhead bei langen Transaktionen (Benutzer A und Benutzer B sperren die Datenbankdaten während des Vorgangs nicht), wodurch die Gesamtleistung des Systems bei hoher Parallelität erheblich verbessert wird. In die Datenzugriffs-Engine von Hibernate ist eine optimistische Sperrimplementierung integriert. Es ist zu beachten, dass Benutzeraktualisierungsvorgänge von externen Systemen nicht von unserem System gesteuert werden, da in unserem System der optimistische Sperrmechanismus implementiert ist. Dies kann dazu führen, dass fehlerhafte Daten in der Datenbank aktualisiert werden.

3. Verwenden Sie zur Steuerung pessimistische Sperren. In den meisten Fällen wird die pessimistische Sperre durch den Sperrmechanismus der Datenbank implementiert, beispielsweise durch die Select ... for update-Anweisung von Oracle, um die maximale Exklusivität des Vorgangs sicherzustellen. Allerdings geht hierdurch ein enormer Mehraufwand bei der Datenbankleistung einher, der insbesondere bei langen Transaktionen oft untragbar ist. Wenn beispielsweise in einem Finanzsystem ein Bediener Benutzerdaten liest und auf Grundlage der gelesenen Benutzerdaten Änderungen vornimmt (z. B. den Kontostand des Benutzerkontos ändert), bedeutet dies, dass der Datenbankeintrag während des gesamten Vorgangs (vom Lesen der Daten durch den Bediener über den Beginn der Datenänderung bis hin zur Übermittlung der Änderungsergebnisse und sogar einschließlich der Zeit, in der der Bediener zwischendurch Kaffee kocht) immer gesperrt ist. Es ist denkbar, dass eine solche Situation bei Hunderten oder Tausenden von gleichzeitigen Vorgängen katastrophale Folgen haben wird. Daher müssen Sie sorgfältig überlegen, ob Sie zur Steuerung eine pessimistische Sperre verwenden.

Die dritte Deadlock-Situation

Wenn in einer Transaktion eine Update-Anweisung ausgeführt wird, die die Bedingungen nicht erfüllt, wird ein vollständiger Tabellenscan durchgeführt und die Sperre auf Zeilenebene wird zu einer Sperre auf Tabellenebene hochgestuft. Nach der Ausführung mehrerer solcher Transaktionen treten wahrscheinlich Deadlocks und Blockierungen auf. Eine ähnliche Situation tritt auf, wenn die Datenmenge in der Tabelle sehr groß ist, aber zu wenige oder ungeeignete Indizes erstellt werden, was zu häufigen vollständigen Tabellenscans führt, was letztendlich dazu führt, dass das Anwendungssystem immer langsamer wird und es schließlich zu Blockaden oder Deadlocks kommt.

Lösung:

Verwenden Sie keine zu komplexen Abfragen, die mehrere Tabellen in SQL-Anweisungen verknüpfen. Verwenden Sie den „Ausführungsplan“ zur Analyse von SQL-Anweisungen und erstellen Sie für SQL-Anweisungen, die vollständige Tabellenscans erfordern, entsprechende Indizes zur Optimierung.

Zusammenfassung

Im Allgemeinen werden Speicherüberläufe und Tabellensperren durch schlecht geschriebenen Code verursacht. Die Verbesserung der Codequalität ist daher die grundlegendste Lösung. Manche Leute denken, sie müssten zuerst die Funktion implementieren und dann während der Testphase etwaige Fehler beheben. Diese Vorstellung ist falsch. So wie die Qualität eines Produkts während des Herstellungsprozesses und nicht während der Qualitätskontrolle bestimmt wird, wird die Qualität von Software während der Entwurfs- und Codierungsphasen bestimmt. Tests sind nur eine Überprüfung der Softwarequalität, da es unmöglich ist, alle Fehler in der Software zu finden.

Oben finden Sie ausführliche Informationen zu den Ursachen und Lösungen für MySQL-Deadlocks. Weitere Informationen zu MySQL-Deadlocks finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!