Inhaltsverzeichnis- 1. Hintergrund
- 2. Langsame Abfrage durch Tabellensperren
- 3. Welche Risiken bestehen bei der Online-Änderung der Tabellenstruktur?
- 4. Analyse eines Deadlock-Problems
- 5. Analyse des Sperrenwarteproblems
- 6. Zusammenfassung
1. Hintergrund Die Verbesserung der Parallelität bei gleichzeitiger Gewährleistung der Datenkonsistenz unter gleichzeitigen Bedingungen mehrerer Benutzer war schon immer das Ziel von Datenbanksystemen. Es ist notwendig, die Anforderungen einer großen Anzahl gleichzeitiger Zugriffe zu erfüllen und gleichzeitig die Sicherheit der Daten unter solchen Bedingungen zu gewährleisten. Um dieses Ziel zu erreichen, verwenden die meisten Datenbanken Sperren und Transaktionsmechanismen, und die MySQL-Datenbank ist da keine Ausnahme. Trotzdem werden wir bei der Geschäftsentwicklung immer noch auf verschiedene schwierige Probleme stoßen. In diesem Artikel werden anhand von Fällen häufige Parallelitätsprobleme demonstriert und Lösungen analysiert. 2. Langsame Abfrage durch Tabellensperren Betrachten wir zunächst einen einfachen Fall und fragen die Informationen eines Benutzers anhand der ID ab: mysql> wähle * vom Benutzer, wobei ID=6 ist; Die Gesamtzahl der Datensätze in dieser Tabelle beträgt 3, die Ausführung dauerte jedoch 13 Sekunden. 
Wenn dieses Problem auftritt, denken wir als Erstes daran, den aktuellen Status des MySQL-Prozesses zu überprüfen: 
Aus dem Vorgang können wir erkennen, dass die Select-Anweisung auf eine Tabellensperre wartet. Welche Abfrage generiert also diese Tabellensperre? Dieses Ergebnis weist keine direkte Korrelation auf, aber wir können davon ausgehen, dass es höchstwahrscheinlich durch die Update-Anweisung generiert wurde (da kein anderes verdächtiges SQL im Prozess vorhanden ist). Um unsere Vermutung zu bestätigen, überprüfen wir zunächst die Struktur der Benutzertabelle: 
Wie erwartet verwendet die Benutzertabelle die MyISAM-Speicher-Engine. MyISAM generiert vor der Ausführung eines Vorgangs eine Tabellensperre und entsperrt diese nach Abschluss des Vorgangs automatisch. Wenn es sich bei dem Vorgang um einen Schreibvorgang handelt, ist der Tabellensperrentyp eine Schreibsperre. Wenn es sich bei dem Vorgang um einen Lesevorgang handelt, ist der Tabellensperrentyp eine Lesesperre. Wie Sie wissen, blockieren Schreibsperren andere Vorgänge (einschließlich Lese- und Schreibvorgänge), wodurch alle Vorgänge seriell werden. Lesesperren können zwar parallel für Lese-/Lesevorgänge verwendet werden, Lese-/Schreibvorgänge sind jedoch weiterhin seriell. Das folgende Beispiel demonstriert den Fall, in dem eine Tabellensperre (Lesesperre) explizit angegeben wird, sowie Lese-Lese-Parallelität und Lese-Schreib-Serialismus. Um Tabellensperren explizit zu öffnen/schließen, verwenden Sie die Lese-/Schreibberechtigung für die Tabellensperre; Sitzung1: 
Sitzung2: 
Sie können sehen, dass Sitzung 1 die Tabellensperre (Lesesperre) aktiviert, um Lesevorgänge auszuführen. Zu diesem Zeitpunkt kann Sitzung 2 parallel Lesevorgänge ausführen, Schreibvorgänge sind jedoch blockiert. Nächste: Sitzung1: 
Sitzung2: 
Wenn Sitzung1 entsperrt wird, beginnt Sitzung2 sofort mit dem Schreiben, d. h. mit dem seriellen Lesen und Schreiben. Zusammenfassen: An diesem Punkt haben wir im Wesentlichen die Ursache des Problems analysiert. Zusammenfassend lässt sich sagen, dass die MyISAM-Speicher-Engine beim Ausführen einer Operation eine Tabellensperre generiert, die sich auf die Operationen anderer Benutzer an der Tabelle auswirkt. Wenn es sich bei der Tabellensperre um eine Schreibsperre handelt, führt dies dazu, dass andere Benutzer seriell arbeiten. Wenn es sich um eine Lesesperre handelt, können die Leseoperationen anderer Benutzer parallel ausgeführt werden. Manchmal stoßen wir auf eine einfache Abfrage, die lange dauert. Prüfen Sie, ob dies der Fall ist. Lösung: 1) Versuchen Sie, die MyISAM-Speicher-Engine nicht zu verwenden. Alle MyISAM-Speicher-Engine-Tabellen wurden in MySQL 8.0 entfernt. Es wird empfohlen, die InnoDB-Speicher-Engine zu verwenden. 2) Wenn Sie die MyISAM-Speicher-Engine verwenden müssen, reduzieren Sie die Zeit für Schreibvorgänge. 3. Welche Risiken bestehen bei der Online-Änderung der Tabellenstruktur? Wenn das Geschäftssystem eines Tages die Länge eines Feldes erhöhen muss, kann dies direkt online geändert werden? Bevor wir diese Frage beantworten, schauen wir uns einen Fall an: 
Die obige Anweisung versucht, die Länge des Namensfelds in der Benutzertabelle zu ändern, und die Anweisung wird blockiert. Wie gewohnt prüfen wir den aktuellen Ablauf: 
Anhand des Vorgangs können wir erkennen, dass die ALTER-Anweisung auf eine Metadatensperre wartet und diese Metadatensperre wahrscheinlich durch die obige SELECT-Anweisung verursacht wird, was tatsächlich der Fall ist. Beim Ausführen von DML-Operationen (Auswählen, Aktualisieren, Löschen, Einfügen) wird der Tabelle eine Metadatensperre hinzugefügt. Diese Metadatensperre soll sicherstellen, dass die Tabellenstruktur während der Abfrage nicht geändert wird. Daher wird die obige Änderungsanweisung blockiert. Was passiert nun, wenn die Ausführungsreihenfolge umgekehrt wird und zuerst die ALTER-Anweisung und dann die DML-Anweisung ausgeführt wird? Werden DML-Anweisungen blockiert? Wenn ich beispielsweise die Tabellenstruktur in einer Onlineumgebung ändere, werden dann die Online-DML-Anweisungen blockiert? Die Antwort ist: ungewiss. Die Online-DDL-Funktion wurde in MySQL 5.6 bereitgestellt und ermöglichte die gleichzeitige Ausführung einiger DDL- und DML-Anweisungen. In der aktuellen Version 5.7 wurde Online-DDL verbessert, sodass die meisten DDL-Operationen online ausgeführt werden können. Einzelheiten finden Sie unter: https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html Daher hängt es vom jeweiligen Szenario ab, ob DML während der DDL-Ausführung in einem bestimmten Szenario blockiert wird. Zusammenfassung: Durch dieses Beispiel haben wir ein grundlegendes Verständnis von Metadatensperren und Online-DDL. Wenn wir während der Geschäftsentwicklung die Tabellenstruktur online ändern müssen, können wir auf die folgenden Lösungen zurückgreifen: 1. Versuchen Sie, es zu einer Zeit durchzuführen, in der das Geschäftsvolumen gering ist. 2. Überprüfen Sie die offizielle Dokumentation, um sicherzustellen, dass die durchzuführende Tabellenänderung gleichzeitig mit DML erfolgen kann und das Online-Geschäft nicht blockiert. 3. Es wird empfohlen, das pt-online-schema-change-Tool von Percona zu verwenden, das leistungsfähiger ist als das offizielle Online-DDL. Sein Grundprinzip lautet: Führen Sie eine vollständige Kopie durch die Anweisung insert...select... durch und verwenden Sie Trigger, um die während des Änderungsprozesses der Tabellenstruktur generierten Inkremente aufzuzeichnen, um den Zweck der Änderung der Tabellenstruktur zu erreichen. Um beispielsweise Tabelle A zu ändern, sind die wichtigsten Schritte: Erstellen Sie eine leere Tabelle der Zieltabellenstruktur A_new.
Erstellen Sie Trigger für Tabelle A, einschließlich Trigger zum Hinzufügen, Löschen und Ändern.
Verwenden Sie die Anweisung „insert...select...limit N“, um Daten fragmentarisch in die Zieltabelle zu kopieren.
Nachdem der Kopiervorgang abgeschlossen ist, benennen Sie die Tabelle A_new in Tabelle A um. 4. Analyse eines Deadlock-Problems In Onlineumgebungen kommt es gelegentlich zu Deadlock-Problemen. Deadlocks werden dadurch verursacht, dass zwei oder mehr Transaktionen darauf warten, dass die Sperren jeweils gegenseitig freigegeben werden. Dies führt dazu, dass die Transaktion nie beendet wird. Um das Problem zu analysieren, simulieren wir eine einfache Deadlock-Situation und fassen anschließend einige Analyseideen daraus zusammen. Demonstrationsumgebung: MySQL5.7.20 Transaktionsisolationsebene: RR Tabellenbenutzer:
CREATE TABLE `Benutzer` (
`id` int(11) NICHT NULL AUTO_INCREMENT,
`name` varchar(300) DEFAULT NULL,
`Alter` int(11) DEFAULT NULL,
PRIMÄRSCHLÜSSEL (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8 Im Folgenden wird die Funktionsweise von Transaktion 1 und Transaktion 2 demonstriert: | Transaktion 1 Transaktion 2 Transaktionsüberwachung T1
beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
T2
Wählen Sie * vom Benutzer mit ID=3 für Aktualisierung;
+----+------+------+
| ID | Name | Alter |
+----+------+------+
| 3 | So | 20 |
+----+------+------+
1 Zeile im Satz (0,00 Sek.)
Wählen Sie * vom Benutzer mit ID=4 für Aktualisierung;
+----+------+------+
| ID | Name | Alter |
+----+------+------+
| 4 | Zhou | 21 |
+----+------+------+
1 Zeile im Satz (0,00 Sek.)
Wählen Sie * aus information_schema.INNODB_TRX;
Durch Abfragen der InnoDB-Transaktionstabelle der Metadatendatenbank wird überwacht, dass die Anzahl der aktuell ausgeführten Transaktionen 2 beträgt, nämlich Transaktion 1 und Transaktion 2.
T3
Benutzersatzname aktualisieren='haha', wobei ID=4;
Da der Datensatz mit der ID=4 durch Transaktion 2 gesperrt wurde, wird die Anweisung blockiert.
Die Anzahl der aktuell laufenden Transaktionen wird auf 2 überwacht. T4 Blockierter Zustand
Benutzersatzname aktualisieren='hehe', wobei ID=3;
FEHLER 1213 (40001): Beim Versuch, eine Sperre zu erhalten, wurde ein Deadlock festgestellt. Versuchen Sie, die Transaktion neu zu starten.
Der Datensatz mit der ID=3 wurde durch Transaktion 1 gesperrt, und diese Transaktion hält die Zeilensperre des Datensatzes mit der ID=4. Zu diesem Zeitpunkt erkennt die InnoDB-Speicher-Engine einen Deadlock, und diese Transaktion wird zurückgesetzt.
Transaktion 2 wird zurückgesetzt, Transaktion 1 läuft jedoch noch. Die Anzahl der aktuell laufenden Transaktionen beträgt 1. T5
Abfrage OK, 1 Zeile betroffen (20,91 Sek.)
Übereinstimmende Zeilen: 1 Geändert: 1 Warnungen: 0
Da Transaktion 2 zurückgesetzt wird, wird die ursprünglich blockierte Update-Anweisung weiterhin ausgeführt.
Die Anzahl der überwachten laufenden Transaktionen beträgt 1. T6
begehen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
Transaktion 1 wurde festgeschrieben, Transaktion 2 wurde zurückgesetzt und die Anzahl der aktuell ausgeführten Transaktionen beträgt 0.
Dies ist ein einfaches Deadlock-Szenario. Transaktion 1 und Transaktion 2 warten darauf, dass die Sperre jeweils aufgehoben wird. Die InnoDB-Speicher-Engine erkennt den Deadlock und führt ein Rollback für Transaktion 2 aus. Dies bedeutet, dass Transaktion 1 nicht mehr auf die Sperre von Transaktion B wartet und mit der Ausführung fortfahren kann. Wie erkennt die InnoDB-Speicher-Engine Deadlocks? Um dieses Problem zu verstehen, überprüfen wir zunächst den Status von InnoDB zu diesem Zeitpunkt:
Engine-InnoDB-Status anzeigen\G
------------------------
Zuletzt erkannter Deadlock
------------------------
14.01.2018 12:17:13 0x70000f1cc000
*** (1) TRANSAKTION:
TRANSAKTION 5120, AKTIV 17 Sek. Start des Indexlesens
MySQL-Tabellen in Verwendung 1, gesperrt 1
LOCK WAIT 3 Sperrstruktur(en), Heap-Größe 1136, 2 Zeilensperren
MySQL-Thread-ID 10, OS-Thread-Handle 123145556967424, Abfrage-ID 2764, Localhost-Root-Aktualisierung
Benutzersatzname aktualisieren='haha', wobei ID=4
*** (1) WARTEN AUF DIE GEWÄHRUNG DIESER SPERRE:
Datensatzsperren, Speicherplatz-ID 94, Seitennummer 3, n Bits 80, Primärindex der Tabelle „Test“. „Benutzer“, TRX-ID 5120, Sperrmodus X sperrt Datensatz, aber nicht Lückenwartezeit
Datensatzsperre, Heap Nr. 5 PHYSIKALISCHER DATENSATZ: n_Felder 5; kompaktes Format; Infobits 0
0: Länge 4; Hex 80000004; aufsteigend ;;
1: Länge 6; Hex 0000000013fa; aufsteigend ;;
2: Länge 7; Hex 520000060129a6; aufsteigend R ) ;;
3: Länge 4; Hex 68616861; asc haha;;
4: Länge 4; Hex 80000015; aufsteigend ;;
*** (2) TRANSAKTION:
TRANSAKTION 5121, AKTIV. 12 Sek. Start des Indexlesens
MySQL-Tabellen in Verwendung 1, gesperrt 1
3 Sperrstruktur(en), Heap-Größe 1136, 2 Zeilensperren
MySQL-Thread-ID 11, OS-Thread-Handle 123145555853312, Abfrage-ID 2765, Localhost-Root wird aktualisiert
Benutzersatzname aktualisieren='hehe', wobei ID=3
*** (2) HÄLT DAS SCHLOSS:
RECORD LOCKS Bereichs-ID 94 Seitennummer 3 n Bits 80 Index PRIMARY der Tabelle `test`.`user` TRX-ID 5121 Sperrmodus X sperrt Datensatz, aber nicht Lücke
Datensatzsperre, Heap Nr. 5 PHYSIKALISCHER DATENSATZ: n_Felder 5; kompaktes Format; Infobits 0
0: Länge 4; Hex 80000004; aufsteigend ;;
1: Länge 6; Hex 0000000013fa; aufsteigend ;;
2: Länge 7; Hex 520000060129a6; aufsteigend R ) ;;
3: Länge 4; Hex 68616861; asc haha;;
4: Länge 4; Hex 80000015; aufsteigend ;;
*** (2) WARTEN AUF DIE GEWÄHRUNG DIESER SPERRE:
Datensatzsperren, Speicherplatz-ID 94, Seitennummer 3, n Bits 80, Primärindex der Tabelle „Test“. „Benutzer“, TRX-ID 5121, Sperrmodus X sperrt Datensatz, aber nicht Lückenwartezeit
Datensatzsperre, Heap Nr. 7 PHYSIKALISCHER DATENSATZ: n_Felder 5; kompaktes Format; Infobits 0
0: Länge 4; Hex 80000003; aufsteigend ;;
1: Länge 6; Hex 0000000013fe; aufsteigend ;;
2: Länge 7; Hex 5500000156012f; aufsteigend UV /;;
3: Länge 4; Hex 68656865; asc hehe;;
4: Länge 4; Hex 80000014; aufsteigend ;;
*** WIR MACHEN DIE TRANSAKTION ZURÜCK (2)
Es gibt viele Indikatoren für den InnoDB-Status. Hier fangen wir Deadlock-bezogene Informationen ab. Es ist ersichtlich, dass InnoDB die jüngsten Deadlock-Informationen ausgeben kann. Tatsächlich werden auch viele Deadlock-Überwachungstools basierend auf dieser Funktion entwickelt.
Die Deadlock-Informationen zeigen Informationen zu zwei Transaktionen, die auf Sperren warten (blau für Transaktion 1 und grün für Transaktion 2). Achten Sie besonders auf WAITING FOR THIS LOCK TO BE GRANTED und HOLDS THE LOCK(S).
WAITING FOR THIS LOCK TO BE GRANTED gibt die Sperrinformationen an, auf die die aktuelle Transaktion wartet. Aus der Ausgabe können wir ersehen, dass Transaktion 1 auf die Zeilensperre mit Heap-Nummer 5 wartet und Transaktion 2 auf die Zeilensperre mit Heap-Nummer 7.
HÄLT DIE SPERRE(N): zeigt die Sperrinformationen an, die von der aktuellen Transaktion gehalten werden. Aus der Ausgabe können wir ersehen, dass Transaktion 2 eine Sperre auf Heap Nr. 5 hält.
Anhand der Ausgabeergebnisse können wir erkennen, dass InnoDB die Transaktion 2 schließlich zurückgesetzt hat.
Wie erkennt InnoDB also Deadlocks?
Der einfachste Weg, den wir uns vorstellen können, besteht darin, dass, wenn eine Transaktion auf eine Sperre wartet und die Wartezeit den festgelegten Schwellenwert überschreitet, der Transaktionsvorgang fehlschlägt. Dadurch wird die Situation vermieden, dass mehrere Transaktionen lange aufeinander warten. Der Parameter innodb_lock_wait_timeout wird verwendet, um die Wartezeit für die Sperre festzulegen.
Wenn diese Methode verwendet wird, dauert es eine Weile, bis der Deadlock behoben ist (d. h. die Wartezeit überschreitet den durch innodb_lock_wait_timeout festgelegten Schwellenwert). Diese Methode ist leicht passiv und beeinträchtigt die Systemleistung. Die InnoDB-Speicher-Engine bietet einen besseren Algorithmus zur Lösung des Deadlock-Problems, den Wait-for-Graph-Algorithmus. Einfach ausgedrückt: Wenn mehrere Transaktionen beginnen, aufeinander zu warten, wird der Wartegraph-Algorithmus aktiviert. Wenn der Algorithmus feststellt, dass ein Deadlock aufgetreten ist, wird eine der Transaktionen sofort zurückgesetzt und der Deadlock aufgelöst. Die Vorteile dieser Methode sind: proaktivere Inspektion und kürzere Wartezeiten.
Hier ist das Grundprinzip des Wait-for-Graph-Algorithmus:
Um es leichter verständlich zu machen, betrachten wir die Sackgasse als ein Szenario, in dem sich vier Autos gegenseitig blockieren:
Die vier Autos werden als vier Transaktionen betrachtet, die auf die Sperre des jeweils anderen warten, was zu einem Deadlock führt. Das Prinzip des Wartegraphenalgorithmus besteht darin, Transaktionen als Knoten zu behandeln und die Sperrwartebeziehung zwischen Transaktionen mit gerichteten Kanten darzustellen. Wenn beispielsweise Transaktion A auf die Sperre von Transaktion B wartet, wird eine gerichtete Kante von Knoten A zu Knoten B gezogen. Wenn der gerichtete Graph, der aus A, B, C und D besteht, einen Zyklus bildet, wird dies als Deadlock beurteilt. Dies ist das Grundprinzip des Wait-for-Graph-Algorithmus.
Zusammenfassen:
1. Wie können wir einen Stillstand in unserer Geschäftsentwicklung erkennen? Wie wir gerade vorgestellt haben, können Sie durch die Überwachung des InnoDB-Status ein kleines Tool zum Sammeln von Deadlock-Datensätzen erstellen, um diese später einfach überprüfen zu können.
2. Wie sollte das Geschäftssystem reagieren, wenn ein Deadlock auftritt? Aus dem Obigen können wir ersehen, dass InnoDB, wenn es einen Deadlock erkennt, dem Client die Meldung „Beim Versuch, eine Sperre zu erhalten, wurde ein Deadlock gefunden; versuchen Sie, die Transaktion neu zu starten“ meldet und die Transaktion zurücksetzt. Die Anwendung muss die Transaktion basierend auf dieser Meldung neu starten und das Protokoll vor Ort für weitere Analysen speichern, um den nächsten Deadlock zu vermeiden.
5. Analyse des Sperrwarteproblems
Bei der Geschäftsentwicklung ist die Wahrscheinlichkeit eines Deadlocks gering, die Wahrscheinlichkeit eines Wartevorgangs auf Sperren jedoch hoch. Der Grund für das Wartevorgang auf Sperren liegt darin, dass eine Transaktion Sperrressourcen für eine lange Zeit belegt, während andere Transaktionen darauf gewartet haben, dass die vorherige Transaktion die Sperre freigibt.
Transaktion 1 Transaktion 2 Transaktionsüberwachung T1
beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
beginnen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)
T2
Wählen Sie * vom Benutzer mit ID=3 für Aktualisierung;
+----+------+------+
| ID | Name | Alter |
+----+------+------+
| 3 | So | 20 |
+----+------+------+
1 Zeile im Satz (0,00 Sek.)
Andere Abfragevorgänge
Wählen Sie * aus information_schema.INNODB_TRX;
Durch Abfragen der InnoDB-Transaktionstabelle der Metadatendatenbank wird überwacht, dass die Anzahl der aktuell ausgeführten Transaktionen 2 beträgt, nämlich Transaktion 1 und Transaktion 2.
T3 Andere Abfrageoperationen
Benutzersatzname aktualisieren='hehe', wobei ID=3;
Da der Datensatz mit der ID=3 durch Transaktion 1 gesperrt ist, wird die Anweisung blockiert (d. h., die Sperre wartet).
Die Anzahl der aktuell laufenden Transaktionen wird auf 2 überwacht. T4 Andere Abfrageoperationen
FEHLER 1205 (HY000): Wartezeit für Sperre überschritten; versuchen Sie, die Transaktion neu zu starten.
Die Wartezeit für die Sperre überschreitet den Schwellenwert und der Vorgang schlägt fehl. Hinweis: Transaktion 2 wird zu diesem Zeitpunkt nicht zurückgesetzt.
Die Anzahl der aktuell laufenden Transaktionen wird auf 2 überwacht. T5-Commit; Transaktion 1 wurde festgeschrieben, Transaktion 2 jedoch nicht. Die Anzahl der aktuell laufenden Transaktionen beträgt 1.
Aus dem Obigen können wir ersehen, dass Transaktion 1 die Zeilensperre mit ID = 3 lange hält und Transaktion 2 eine Sperrwartezeit generiert. Der Vorgang wird unterbrochen, nachdem die Wartezeit innodb_lock_wait_timeout überschritten hat, die Transaktion wird jedoch nicht zurückgesetzt. Wenn bei der Geschäftsentwicklung eine Wartesperre auftritt, wirkt sich dies nicht nur auf die Leistung aus, sondern stellt auch eine Herausforderung für Ihren Geschäftsprozess dar, da Ihr Geschäftsende eine adaptive logische Verarbeitung für die Wartesperre-Situation durchführen muss, um zu entscheiden, ob der Vorgang wiederholt oder die Transaktion rückgängig gemacht werden soll.
Die MySQL-Metadatentabellen sammeln Informationen zu Transaktionen und Sperrwartevorgängen, wie z. B. INNODB_LOCKS, INNODB_TRX und INNODB_LOCK_WAITS unter der Datenbank information_schema. Sie können diese Tabellen verwenden, um den Sperrwartevorgangsstatus Ihres Geschäftssystems zu beobachten. Um den Zusammenhang zwischen Transaktionen und Sperrwartezeiten bequem abzufragen, können Sie auch folgende Anweisung verwenden:
| SELECT r.trx_id warte_trx_id, r.trx_mysql_thread_id warte_thread, r.trx_query warte_abfrage, b.trx_id blockiere_trx_id, b.trx_mysql_thread_id blockiere_thread, b.trx_query blockiere_abfrage FROM information_schema.innodb_lock_waits w INNER JOIN information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id INNER JOIN information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id; Ergebnis:
wartende_trx_id: 5132
Wartethread: 11
watching_query: Benutzersatzname aktualisieren='hehe', wobei id=3
Blockierungs-TRX-ID: 5133
blockierender_Thread: 10
Blockierungsabfrage: NULL
Zusammenfassen:
1. Überwachen Sie die Sperrwartezeit Ihres Geschäftssystems. Dies hilft Ihnen, die aktuelle Datenbanksperrsituation zu verstehen und Ihre Geschäftsabläufe zu optimieren.
2. Im Geschäftssystem muss für Situationen, in denen es zu einer Wartezeitüberschreitung bei Sperren kommt, eine entsprechende logische Beurteilung vorgenommen werden.
6. Zusammenfassung
Dieser Artikel stellt anhand einiger einfacher Beispiele einige häufige MySQL-Parallelitätsprobleme vor und versucht, Ideen zur Behebung dieser Probleme zu liefern. In diesem Artikel geht es um Transaktionen, Tabellensperren, Metadatensperren und Zeilensperren. Darüber hinaus können jedoch noch weitaus mehr Parallelitätsprobleme auftreten, wie z. B. Transaktionsisolationsebenen, GAP-Sperren usw. Echte Parallelitätsprobleme können zahlreich und komplex sein, aber die Ideen und Methoden zur Fehlerbehebung können wiederverwendet werden. In diesem Artikel haben wir zur Fehlerbehebung und Erkennung von Problemen die Funktionen „Show Processlist“, „Show Engine InnoDB Status“ und „Query Metadata Tables“ verwendet. Wenn das Problem eine Replikation betrifft, ist zur Unterstützung auch eine Master/Slave-Überwachung erforderlich.
Das könnte Sie auch interessieren:- So handhaben Sie gleichzeitige Aktualisierungen von MySQL-Daten
- Erläuterung zur Optimierung der Tomcat+MySQL-Konfiguration mit hoher Parallelität
- PHP verwendet Mysql Lock, um hohe Parallelität zu lösen
- Lösung für das Problem der gesperrten Transaktionsverarbeitung mit hoher Parallelität in PHP+MySQL
- Yii+MYSQL-Sperrtabelle, um doppelte Daten in gleichzeitigen Situationen zu verhindern
- Implementierung leistungsstarker und gleichzeitig nutzbarer Zählerlösungen in MySQL (z. B. Artikel-Klickzähler)
- Gemeinsame Nutzung von Lösungen für das Problem gleichzeitiger Aktualisierungen in SELECT+UPDATE in MySQL
- Beispiel für die Verwendung von MySQL-Transaktionsfunktionen zur Implementierung einer gleichzeitigen und sicheren Auto-Increment-ID
- Ausführliche Erläuterung der MySQL-Optimierung für gleichzeitige Einfügungen
- Lösung für das Problem der MySQL-Transaktionsparallelität
|---|
