MySQL konzentriert sich auf die Leistung und die detaillierte Erläuterung der zugehörigen Analysebefehle

1. MySQL-Leistungsüberwachung betrifft

QPS (Abfragen pro Sekunde): Das QPS bezieht sich hier tatsächlich auf die Gesamtzahl der von MySQL Server pro Sekunde ausgeführten Abfragen:
QPS = Abfragen / Sekunden

TPS (Transaktionen pro Sekunde): Es gibt keinen direkten Transaktionszähler in MySQL Server. Wir können das Transaktionsvolumen des Systems nur durch Rollback- und Commit-Zähler berechnen. Daher müssen wir den von der Clientanwendung angeforderten TPS-Wert auf folgende Weise erhalten:
TPS = (Com_commit Com_rollback) / Sekunden

Schlüsselpuffer-Trefferrate: Schlüsselpuffer-Treffer Die Rate stellt die Cache-Trefferrate des Index der MyISAM-Typtabelle dar. Die Größe dieser Trefferquote wirkt sich direkt auf die Lese- und Schreibleistung von Tabellen vom Typ MyISAM aus. Die Trefferquote des Schlüsselpuffers
umfasst tatsächlich die Trefferquote des Lesens und des Schreibens. Die Werte dieser beiden Trefferquoten werden in MySQL nicht direkt angegeben, können jedoch wie folgt berechnet werden:
key_buffer_read_hits = ( 1 - Key_reads / Key_read_requests) * 100 %
key_buffer_write_hits= (1 - Key_writes / Key_write_requests) * 100 %

Innodb-Puffer-Trefferquote: Hier bezieht sich Innodb-Puffer auf innodb_buffer_poolDas heißt, den Speicher Speicherplatz, der zum Zwischenspeichern von Daten und Indizes von Tabellen vom Typ Innodb verwendet wird. Ähnlich wie beim Schlüsselpuffer
können wir auch seine Trefferquote basierend auf dem entsprechenden Statuswert berechnen, der von MySQL Server bereitgestellt wird:
innodb_buffer_read_hits=(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%

Abfrage-Cache-Trefferquote: Wenn wir den Abfrage-Cache verwenden, ist es auch notwendig, die Abfrage-Cache-Trefferquote zu überwachen, da sie uns möglicherweise Aufschluss darüber gibt, ob wir den Abfrage-Cache korrekt verwenden.
Die Trefferquote des Abfrage-Cache wird wie folgt berechnet:
Query_cache_hits= (Qcache_hits / (Qcache_hits Qcache_inserts)) * 100 %

Table Cache-Status: Der aktuelle Status des Table Cache kann uns helfen zu beurteilen, ob die Einstellung des Systemparameters table_open_cache angemessen ist. Wenn das Verhältnis zwischen den Statusvariablen Open_tables und Opened_tables zu niedrig ist, bedeutet dies, dass die Einstellung für den Tabellencache zu klein ist:
SHOW STATUS LIKE 'Open%';

Thread-Cache-Trefferrate: Thread-Cache-Treffer Die Rate kann direkt widerspiegeln. Überprüfen Sie, ob unser Systemparameter thread_cache_size richtig eingestellt ist. Ein angemessener thread_cache_size-Parameter kann
viele Ressourcen einsparen, die zum Erstellen neuer Verbindungen erforderlich sind.
Thread-Cache-Trefferrate wird wie folgt berechnet:
Thread_cache_hits = (1 - Threads_created / Connections) * 100 %

Sperrstatus: Der Sperrstatus umfasst Tabellensperre und Zeilensperre. Wir können das System übergeben Die Statusvariable enthält die Gesamtzahl der erhaltenen Sperren, die Anzahl der Wartezeiten anderer Threads durch die Sperre sowie Informationen zur Sperrwartezeit.
SHOW STATUS LIKE '%lock%';
Über die sperrenbezogenen Systemvariablen können wir die Gesamtzahl der Tabellensperren ermitteln, einschließlich der Häufigkeit, mit der andere vorhandene Threads warten. Gleichzeitig können Sie auch sehr detaillierte Informationen zur Zeilensperre abrufen, z. B. die Gesamtzahl der Zeilensperren, die Gesamtzeit der Zeilensperre, die Wartezeit für jede Zeilensperre, die maximale Wartezeit, die durch Zeilensperren verursacht wird, und die Anzahl der Threads, die derzeit auf Zeilensperren warten. Durch die Überwachung dieser Mengen können wir klar erkennen, ob die Gesamtsystemblockade schwerwiegend ist. Wenn das Verhältnis von Table_locks_waited zu Table_locks_immediate groß ist, bedeutet dies, dass die durch unsere Tabellensperren verursachte Blockierung schwerwiegend ist und die Abfrageanweisung möglicherweise angepasst werden muss, die Speicher-Engine möglicherweise geändert werden muss oder die Geschäftslogik geändert werden muss angepasst. Natürlich müssen spezifische Verbesserungsmethoden anhand tatsächlicher Szenarien beurteilt werden. Wenn Innodb_row_lock_waits größer ist, bedeutet dies, dass die Zeilensperre von Innodb ebenfalls schwerwiegend ist und die normale Verarbeitung anderer Threads beeinträchtigt. Auch die Ursache muss gefunden und behoben werden. Die Ursache für schwerwiegende Innodb-Zeilensperren kann darin liegen, dass der von der Abfrageanweisung verwendete Index nicht sinnvoll genug ist (Innodb-Zeilensperren werden basierend auf Indizes gesperrt), was dazu führt, dass die Lückensperre zu groß ist. Es kann auch sein, dass das System selbst über begrenzte Verarbeitungsfähigkeiten verfügt und andere Aspekte (z. B. Hardwaregeräte) berücksichtigt werden müssen.

Replikationsverzögerung: Die Replikationsverzögerung wirkt sich direkt darauf aus, wie lange sich die Slave-Datenbank in einem inkonsistenten Zustand befindet.
Führen Sie den Befehl „SHOW SLAVE STATUS“ auf dem Slave-Knoten aus und rufen Sie den Wert des Elements Seconds_Behind_Master ab, um die aktuelle Verzögerung des Slaves zu verstehen (Einheit: Sekunden).

Tmp-Tabellenstatus: Der Status der Tmp-Tabelle wird hauptsächlich verwendet, um zu überwachen, ob MySQL zu viele temporäre Tabellen verwendet und ob temporäre Tabellen zu groß sind und aus dem Speicher auf Festplattendateien ausgelagert werden müssen. Informationen zum temporären Tabellennutzungsstatus können über die folgenden Methoden abgerufen werden:
SHOW STATUS LIKE 'Created_tmp%';
--------- -------
|. Variablenname |. Wert |
-------- -------
|. Created_tmp_disk_tables |. 0 |
| Created_tmp_tables |
--------- -
Wenn Created_tmp_tables sehr groß ist, gibt es möglicherweise zu viele Sortiervorgänge im System oder die Tabellenverbindungsmethode ist nicht sehr optimiert. Und wenn das Verhältnis von Created_tmp_disk_tables zu Created_tmp_tables zu hoch ist, beispielsweise mehr als 10 %, müssen wir prüfen, ob der Systemparameter tmp_table_size groß genug eingestellt ist.


Nutzungsstatus des Binlog-Cache: Der Binlog-Cache wird zum Speichern von Binlog-Informationen verwendet, die noch nicht auf die Festplatte geschrieben wurden.
Die relevanten Statusvariablen lauten wie folgt:
SHOW STATUS LIKE 'Binlog_cache%';
Der Wert von Binlog_cache_disk_use ist nicht 0, was bedeutet, dass die Binlog-Cache-Größe möglicherweise nicht ausreicht, und die Systemparametergröße binlog_cache_size erhöht werden kann.

Innodb_log_waits-Volumen: Die Statusvariable Innodb_log_waits spiegelt direkt die Anzahl der Wartezeiten wider, die durch unzureichenden Speicherplatz im Innodb-Protokollpuffer verursacht werden.
STATUS WIE 'Innodb_log_waits' anzeigen;
Die Häufigkeit des Auftretens dieses Variablenwerts wirkt sich direkt auf die Schreibleistung des Systems aus. Wenn der Wert also einmal pro Sekunde erreicht, sollte der Wert des Systemparameters innodb_log_buffer_size sein Schließlich ist dies der Fall. Ein vom System gemeinsam genutzter Cache verursacht bei entsprechender Vergrößerung keine Probleme mit unzureichendem Speicher.

2. Detaillierte Erläuterung der Leistungsanalysebefehle

SHOW STATUS;
FLUSH STATUS;

Zeigen Sie die aktuelle Anzahl von VerbindungenSHOW STATUS LIKE 'Thread_%';
Thread_cached: die Anzahl der zwischengespeicherten Threads
Thread_running: active Die Anzahl von Threads
Thread_connected: die Anzahl der aktuell verbundenen Threads
Thread_created: die Gesamtzahl der erstellten Threads

Thread-Cache-Treffer
Thread_connected = SHOW GLOBAL STATUS LIKE Thread_created;
Connections = SHOW GLOBAL STATUS WIE 'Verbindungen';
TCH=(1 - (Threads_created / Connections)) * 100

Aktiven Verbindungsinhalt anzeigen
PROZESSLISTE ANZEIGEN;

Wenn die Anzahl der TCH beträgt weniger als 90 %, es braucht Zeit, um die Verbindung herzustellen, erhöhen Sie die Anzahl der Thread_cached

QPS (Abfrageverarbeitung pro Sekunde) MyISAM-Engine

Fragen = SHOW GLOBAL STATUS LIKE 'Fragen'
Uptime = SHOW GLOBAL STATUS LIKE 'Uptime';
QPS=Fragen/Uptime

TPS (Anzahl der pro Sekunde übertragenen Transaktionen), also die Anzahl der vom Server pro Sekunde verarbeiteten Transaktionen, wenn InnoDB angezeigt wird, aber ohne InnoDB nicht angezeigt wird.

Com_commit = GLOBAL STATUS WIE 'Com_commit' anzeigen;
Com_rollback = GLOBAL STATUS WIE 'Com_rollback' anzeigen;
Uptime = GLOBAL STATUS WIE 'Uptime' anzeigen;
TPS=(Com_commit Com_rollback )/Betriebszeit

QPS- und TPS-Werte müssen in Echtzeit überwacht werden, wenn sie während der Architekturerstellung nahe am Testpeak liegen, möge Gott mit Ihnen sein

Lese-/Schreibverhältnis
Qcache_hits = GLOBAL STATUS ANZEIGEN WIE 'Qcache_hits';
Com_select = GLOBAL STATUS ANZEIGEN WIE 'Com_select';
Com_insert = GLOBAL STATUS ANZEIGEN WIE 'Com_insert';
Com_update = GLOBAL STATUS ANZEIGEN WIE 'Com_update' ;
Com_delete = GLOBAL STATUS WIE 'Com_delete' anzeigen;
Com_replace = GLOBAL STATUS WIE 'Com_replace' anzeigen;
R/W=(Com_select Qcache_hits) / (Com_insert Com_update Com_delete Com_replace) * 100

Lese-Schreib-Verhältnis, eine wichtige Grundlage für die Optimierung der Datenbank, optimiert das Lesen, wenn viel gelesen wird, und optimiert das Schreiben, wenn viel geschrieben wird

Langsame Abfragen pro Minute
Slow_queries = GLOBAL STATUS WIE 'Slow_queries' anzeigen;
Uptime = GLOBAL STATUS WIE 'Uptime' anzeigen;
SQPM=Slow_queries / (Uptime/60)

Langsame Abfragen/Fragen-Verhältnis
Slow_queries = SHOW GLOBAL STATUS LIKE 'Slow_queries';
Questions = SHOW GLOBAL STATUS LIKE 'Questions';
S/Q=Slow_queries/Questions

Konzentrieren Sie sich beim Start der neuen Version auf langsame Abfragen

Full_join pro Minute
Select_full_join = GLOBAL STATUS WIE 'Select_full_join' anzeigen;
Uptime = GLOBAL STATUS WIE 'Uptime' anzeigen;
FJPM=Select_full_join / (Uptime/60)

Full_join verursacht durch Nichtverwendung des Index, optimieren Sie den Index

Innodb-Puffer-Lesetreffer
Innodb_buffer_pool_reads = SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
Innodb_buffer_pool_read_requests = SHOW GLOBAL STATUS LIKE 'Innodb_buffer_ pool_read_requests';
IFRH=(1 - Innod b_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100

InnoDB-Puffer-Trefferratenziel 95 %–99 %;

Tabellen-Cache
Open_tables= SHOW GLOBAL STATUS LIKE 'Open_tables' ;
Opened_tables= GLOBAL STATUS WIE 'Opened_tables' anzeigen;
table_cache= GLOBAL STATUS WIE 'table_cache' anzeigen;

table_cache sollte größer als Open_tables und kleiner als Opened_tables sein

Verhältnis temporärer Tabellen zu Datenträger

Created_tmp_tables = globalen Status wie „Created_tmp_tables“ anzeigen;
Created_tmp_disk_tables = globalen Status wie „Created_tmp_disk_tables“ anzeigen;

TDR=(Created_tmp_disk_tables/Created_tmp_tables)*100

GLOBAL STATUS WIE 'Innodb_row_lock_%' anzeigen;

Innodb_row_lock_current_waits

Die Anzahl der Zeilensperren, auf die derzeit gewartet wird. In MySQL 5.0.3 hinzugefügt.

Innodb_row_lock_time

Die Gesamtzeit, die für den Erwerb von Zeilensperren aufgewendet wurde, in Millisekunden.

Innodb_row_lock_time_avg

Die durchschnittliche Zeit zum Erwerb einer Zeilensperre in Millisekunden. Hinzugefügt in MySQL 5.0.3.

Innodb_row_lock_time_max

Die maximale Zeit zum Erwerb einer Zeilensperre, in Millisekunden. Hinzugefügt in MySQL 5.0.3.

Innodb_row_lock_waits

Die Anzahl, wie oft auf eine Zeilensperre gewartet werden musste.