Heim >Datenbank >MySQL-Tutorial >MySQL-Artefakt zeigt vollständige Prozessliste
Beim heutigen Synchronisieren der Testdaten wurde die Netzwerkverbindung plötzlich getrennt. Nach dem erneuten Herstellen der Verbindung stellte ich fest, dass die Tabelle nicht geöffnet werden konnte.
Sie können sehen, dass die Datenlänge der Tabelle 112192 KB beträgt, sie kann jedoch leider nicht geöffnet werden.
Wenn Sie es nicht öffnen können, bereiten Sie das Löschen vor und versuchen Sie es erneut.
Natürlich ist es oft nicht so einfach, es konnte weder gelöscht noch abgeschnitten werden. Dann blieb Navicat hängen, also loggte ich mich in die Datenbank ein und führte einen Dorp-Vorgang durch, aber es funktionierte immer noch nicht arbeiten.
Möglicherweise handelt es sich um einen Netzwerkfehler, der dazu führt, dass einige seltsame Dinge passieren.
Dann lasst uns einen Blick darauf werfen und sehen, was passiert ist.
Das Artefakt erscheint.
vollständige Prozessliste anzeigen;
vollständige Prozessliste anzeigen Das Ergebnis gab Änderungen in Echtzeit zurück und ist ein Live-Schnappschuss der MySQL-Link-Ausführung, sodass es für die Handhabung sehr nützlich ist Notfälle es funktioniert.
Dieses SQL fungiert normalerweise als Feuerwehrmann, um einige plötzliche Probleme zu lösen.
Es kann einige aktuelle Betriebsbedingungen von MySQL überprüfen, ob Druck herrscht, welches SQL ausgeführt wird, wie viel Zeit die Anweisung benötigt, ob langsames SQL ausgeführt wird usw.
Wenn Sie eine SQL finden, deren Ausführung lange dauert, müssen Sie bei Bedarf mehr darauf achten, sie zu beenden und das Problem zuerst zu lösen. Der Befehl
verfügt über drei Ausführungsmethoden:
1. Dies dient zur direkten Abfrage in der Befehlszeile. Das G am Ende bedeutet, dass die Abfrageergebnisse in Spalten gedruckt werden Das Feld kann in ein separates OK gedruckt werden.
mysql> show full processlist; +--------+------+----------------------+-------+---------+------+----------+-----------------------+ | Id | User | Host | db | Command | Time | State | Info | +--------+------+----------------------+-------+---------+------+----------+-----------------------+ | 449000 | root | 127.123.213.11:59828 | stark | Sleep | 1270 | | NULL | | 449001 | root | 127.123.213.11:59900 | stark | Sleep | 1241 | | NULL | | 449002 | root | 127.123.213.11:59958 | stark | Sleep | 1216 | | NULL | | 449003 | root | 127.123.213.11:60088 | stark | Sleep | 1159 | | NULL | | 449004 | root | 127.123.213.11:60108 | stark | Sleep | 1151 | | NULL | | 449005 | root | 127.123.213.11:60280 | stark | Sleep | 1076 | | NULL | | 449006 | root | 127.123.213.11:60286 | stark | Sleep | 1074 | | NULL | | 449007 | root | 127.123.213.11:60344 | stark | Sleep | 1052 | | NULL | | 449008 | root | 127.123.213.11:60450 | stark | Sleep | 1005 | | NULL | | 449009 | root | 127.123.213.11:60498 | stark | Sleep | 986 | | NULL | | 449013 | root | localhost | NULL | Query | 0 | starting | show full processlist | +--------+------+----------------------+-------+---------+------+----------+-----------------------+ 11 rows in set (0.01 sec) mysql> show full processlist\G; *************************** 1. row *************************** Id: 449000 User: root Host: 127.123.213.11:59828 db: stark Command: Sleep Time: 1283 State: Info: NULL *************************** 2. row *************************** Id: 449001 User: root Host: 127.123.213.11:59900 db: stark Command: Sleep Time: 1254 State: Info: NULL
2. Sehen Sie sich den Snapshot an, indem Sie die Tabellen zum Link-Thread abfragen
SELECT id, db, USER, HOST, command, time, state, info FROM information_schema ! = 'Sleep' ORDER BY time DESC;
3. Ansicht über [Tools] => [Serverüberwachung] in Navicat.
Diese Methode ist bequemer und kann auch sortiert werden.
Eine kurze Einführung in die Bedeutung jeder Spalte:
ID: Die eindeutige Kennung des Link-MySQL-Server-Threads. Sie können den Link dieses Threads durch Kill beenden.
Benutzer: Der Benutzer des aktuellen Threads, der eine Verbindung zur Datenbank herstellt
Host: Zeigt an, von welcher IP und von welchem Port diese Anweisung gesendet wurde. Kann verwendet werden, um den Benutzer zu verfolgen, der die problematische Anweisung ausgegeben hat
db: Die Datenbank des Thread-Links, null, wenn keine vorhanden ist
Befehl: Zeigt normalerweise den ausgeführten Befehl der aktuellen Verbindung an Ruhezustand oder Leerlauf (Ruhezustand), Abfrage, Verbindung
Zeit: Die Zeit, die sich der Thread im aktuellen Status befindet, in Sekunden
Status: Zeigt den Status der SQL-Anweisung unter Verwendung der aktuellen Verbindung an. Sehr wichtige Spalte, es wird später eine Beschreibung aller Zustände geben. Bitte beachten Sie, dass es sich bei dem Zustand nur um einen bestimmten Zustand bei der Ausführung einer SQL-Anweisung handelt. Möglicherweise muss das Ergebnis in die tmp-Tabelle kopiert werden , Senden von Daten und anderen Zuständen. Vollständig
Info: Vom Thread ausgeführte SQL-Anweisung oder null, wenn keine Anweisung ausgeführt wird. Diese Anweisung kann eine vom Kunden gesendete Ausführungsanweisung oder eine interne Ausführungsanweisung sein
Wie kann das Problem gelöst werden, nachdem es entdeckt wurde?
1. Sie können die oben genannten problematischen Zeilen einzeln beenden
449000 töten
2 Sie können Threads, die länger als 3 Minuten dauern, auch stapelweise beenden
- - Threads abfragen, deren Ausführungszeit 3 Minuten überschreitet, und sie dann in Kill-Anweisungen zusammenfügen
select concat('kill ', id, ';')
from information_schema.processlist
wobei command != 'Sleep'
and time > 3*60
order by time desc;
Natürlich kann das Problem damit meist gelöst werden Punkt, aber das Während des Show Processlist-Prozesses habe ich zum ersten Mal nur die vorherigen Abschneide- und Löschvorgänge gesehen und diese beiden Threads getötet, was keinen Nutzen hatte. . . .
Natürlich ist das oben Genannte kein Unsinn, das ist etwas Ähnliches wie bei [Chinese Captain]: Wenn Sie auf einen Flugunfall stoßen, überprüfen Sie ihn zuerst anhand des Handbuchs, untersuchen Sie die Ursache und lösen Sie das Problem Problem.
Weiter
Unmittelbar danach habe ich Navicat verwendet, um den Tabellenreparaturvorgang durchzuführen, und das Ergebnis war Warten auf Tabellenmetadatensperre
Als MySQL einige DDL-Vorgänge ausführte, z Wenn die Tabelle nicht festgeschriebene Transaktionen enthält, wird auf eine Tabellenmetadatensperre gewartet. Sobald eine Metadatensperre auftritt, werden nachfolgende Vorgänge für die Tabelle blockiert.
Lösung:
1. Sehen Sie sich die derzeit nicht festgeschriebenen Transaktionen aus der Tabelle information_schema.innodb_trx an
wählen Sie trx_state, trx_started, trx_mysql_thread_id, trx_query aus information_schema.innodb_trxG
Feldbedeutung:
trx_state: Transaktionsstatus, normalerweise RUNNING
trx_started: Startzeit der Transaktionsausführung. Wenn die Zeit lang ist, analysieren Sie, ob die Transaktion angemessen ist
trx_mysql_thread_id : Die Thread-ID von MySQL, die zum Töten verwendet wird
trx_query: SQL in der Transaktion
Im Allgemeinen warten DDL-Vorgänge nicht auf die Tabellenmetadatensperre, solange diese Threads beendet sind.
2. Passen Sie den Sperr-Timeout-Schwellenwert an
lock_wait_timeout stellt das Timeout für den Erwerb der Metadatensperre dar (in Sekunden), und der zulässige Wertebereich liegt zwischen 1 und 31536000 (1 Jahr). Der Standardwert ist 31536000.
Siehe https://dev.mysql.com/doc/refman/5.6/en/se...
Der Standardwert ist ein Jahr. . . .
Stellen Sie es auf 30 Minuten ein
Setzen Sie die Sitzungssperre lock_wait_timeout = 1800;
Setzen Sie die globale Sperre lock_wait_timeout = 1800;
damit es bei diesem Problem schnell fehlschlägt auftritt (ausfallsicher).
Empfohlene Tutorials: „MySQL-Tutorial“ „Navicat“
Das obige ist der detaillierte Inhalt vonMySQL-Artefakt zeigt vollständige Prozessliste. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!