Ursachen und Lösungen von Datenbank-Deadlocks

Ursachen und Lösungen für Datenbank-Deadlocks: 1. Ein Fehler tritt im Programm auf und die Logik des Programms muss angepasst werden. 2. Die Schaltflächen auf der Seite werden nicht sofort wirksam und optimistische Sperren und Zur Steuerung müssen pessimistische Sperren verwendet werden. 3. Führen Sie mehrere Aktualisierungsanweisungen aus, die die Bedingungen nicht erfüllen. Die Anweisungen müssen analysiert und entsprechende Indizes zur Optimierung erstellt werden.

Ursachen und Lösungen für Datenbank-Deadlocks:

Es gibt zwei grundlegende Arten von Sperren in der Datenbank: 排它锁 (Exklusive Sperren, d. h. X-Sperre) und 共享锁 (Freigabesperren, d. h. S-Sperre). Wenn ein Datenobjekt exklusiv gesperrt ist, können andere Transaktionen es nicht lesen oder ändern. Datenobjekte mit gemeinsamer Sperre 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.

Verwandte Grafik-Tutorials: MySQL-Datenbank-Grafik-Tutorials

Die erste Deadlock-Situation

A 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 die Tabelle gesperrt hat B. Es muss darauf warten, dass Benutzer B Tabelle B freigibt, bevor es fortfahren kann. Ebenso muss Benutzer B darauf warten, dass Benutzer A Tabelle A freigibt, bevor es fortfahren kann.

Lösung:

Diese Art von Deadlock kommt relativ häufig vor und wird durch Fehler im Programm verursacht. Es gibt keine andere Lösung, als die Logik des Programms anzupassen. Analysieren Sie die Logik des Programms sorgfältig, versuchen Sie, sie in derselben Reihenfolge zu verarbeiten, und vermeiden Sie, dass zwei Ressourcen gleichzeitig gesperrt werden. Wenn Sie beispielsweise zwei Tabellen A und B betreiben, sollten Sie sie immer verarbeiten in der Reihenfolge A zuerst und dann B. Wenn zwei Ressourcen gleichzeitig gesperrt werden müssen, muss sichergestellt werden, dass die Ressourcen jederzeit in derselben Reihenfolge gesperrt werden.

Der zweite Fall von Deadlock

Benutzer A fragt einen Datensatz ab und ändert dann den Datensatz, dann ändert Benutzer B den Datensatz, dann Benutzer A. Die Art der Sperre Die Transaktion versucht, von der gemeinsamen Sperre der Abfrage auf eine exklusive Sperre zu steigen, und die exklusive Sperre in Benutzer B muss darauf warten, dass A die gemeinsame Sperre aufhebt, da A über eine gemeinsame Sperre verfügt und A aufgrund der exklusiven Sperre von B nicht erhöht werden kann. Es ist der exklusiven Sperre nicht möglich, die gemeinsam genutzte Sperre freizugeben, sodass ein Deadlock auftritt. Diese Art von Deadlock ist relativ versteckt, kommt aber bei größeren Projekten häufig vor. Wenn beispielsweise in einem Projekt auf eine Schaltfläche auf der Seite geklickt wird, wird die Schaltfläche nicht sofort ungültig, sodass der Benutzer schnell mehrmals auf dieselbe Schaltfläche klickt. Auf diese Weise führt derselbe Codeteil mehrere Vorgänge für denselben aus Datensatz in der Datenbank, und eine solche Sperrsituation kann leicht auftreten.

Lösung:

1 Machen Sie Steuerelemente wie Schaltflächen sofort nach dem Klicken ungültig, um zu verhindern, dass Benutzer wiederholt klicken und gleichzeitig denselben Datensatz bearbeiten zur gleichen Zeit.

2. Verwenden Sie optimistisches Sperren zur Kontrolle. Optimistisches Sperren wird hauptsächlich basierend auf dem Aufzeichnungsmechanismus der Datenversion (Version) implementiert. Das heißt, den Daten eine Versionskennung hinzuzufügen. In Versionslösungen, die auf Datenbanktabellen basieren, wird dies normalerweise durch Hinzufügen eines „Version“-Felds zur Datenbanktabelle erreicht. Beim Auslesen der Daten wird auch diese Versionsnummer ausgelesen und bei einer späteren Aktualisierung wird diese 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 aktualisiert, andernfalls werden sie als abgelaufene Daten betrachtet. Der optimistische Sperrmechanismus vermeidet den Datenbanksperraufwand bei langen Transaktionen (weder Benutzer A noch Benutzer B sperren die Datenbankdaten während des Vorgangs), was die Gesamtleistung des Systems bei großer Parallelität erheblich verbessert. Hibernate verfügt über eine optimistische Sperrimplementierung, die in seine Datenzugriffs-Engine integriert ist. Es ist zu beachten, dass aufgrund der Implementierung des optimistischen Sperrmechanismus in unserem System Benutzeraktualisierungsvorgänge von externen Systemen nicht von unserem System kontrolliert werden, sodass fehlerhafte Daten möglicherweise in der Datenbank aktualisiert werden.

3. Verwenden Sie pessimistische Sperren zur Kontrolle. In den meisten Fällen basiert das pessimistische Sperren auf dem Sperrmechanismus der Datenbank, z. B. der Select... for update-Anweisung von Oracle, um die maximale Exklusivität des Vorgangs sicherzustellen. Was jedoch folgt, ist ein großer Overhead bei der Datenbankleistung, insbesondere bei langen Transaktionen, ein solcher Overhead ist oft unerträglich. Wenn beispielsweise in einem Finanzsystem ein Bediener Benutzerdaten liest und auf der Grundlage der gelesenen Benutzerdaten Änderungen vornimmt (z. B. das Ändern des Benutzerkontostands), bedeutet dies, dass der gesamte Operationsprozess (der) bei Verwendung eines pessimistischen Sperrmechanismus abläuft Der gesamte Prozess vom Lesen der Daten durch den Bediener über den Beginn der Änderung bis zur Übermittlung des Änderungsergebnisses und sogar einschließlich der Zeit, zu der der Bediener zwischendurch Kaffee kochen wollte, ist, dass die Datenbankeinträge immer gesperrt sind oder Tausende von Parallelität, eine solche Situation wird katastrophale Folgen haben. Daher müssen Sie dies sorgfältig abwägen, wenn Sie eine pessimistische Sperrsteuerung verwenden.

Die dritte Deadlock-Situation

Wenn in einer Transaktion eine Aktualisierungsanweisung ausgeführt wird, die die Bedingungen nicht erfüllt, wird ein vollständiger Tabellenscan durchgeführt und die Sperre auf Zeilenebene auf eine Sperre auf Tabellenebene aktualisiert. Nachdem mehrere solcher Transaktionen ausgeführt wurden, kommt es zu Deadlocks und Blockierungen kann leicht passieren. Eine ähnliche Situation tritt auf, wenn die Datenmenge in der Tabelle sehr groß ist und die Anzahl der erstellten Indizes zu gering oder unangemessen ist, was zu häufigen vollständigen Tabellenscans führt. Am Ende wird das Anwendungssystem immer langsamer und blockiert oder es kommt zu einem Deadlock.

Lösung:

Verwenden Sie keine zu komplexen Abfragen, die mehrere Tabellen in SQL-Anweisungen in Beziehung setzen. Verwenden Sie den „Ausführungsplan“, um die SQL-Anweisung zu analysieren die SQL-Anweisungen und erstellen entsprechende Indizes zur Optimierung.

Verwandte Lernempfehlungen: MySQL-Video-Tutorial

Das obige ist der detaillierte Inhalt vonUrsachen und Lösungen von Datenbank-Deadlocks. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!