Eine kurze Einführung in MySQL-Datenbankoptimierungstechniken

Eine ausgereifte Datenbankarchitektur ist nicht von Anfang an auf hohe Verfügbarkeit, hohe Skalierbarkeit und andere Funktionen ausgelegt. Erst mit zunehmender Benutzerzahl wird die Infrastruktur schrittweise verbessert. In diesem Artikel werden hauptsächlich die Probleme und Optimierungslösungen erörtert, mit denen MySQL-Datenbanken während ihres Entwicklungszyklus konfrontiert sind. Wenn man von der Front-End-Anwendung absieht, kann man sie grob in die folgenden fünf Phasen unterteilen:

Phase 1: Entwurf der Datenbanktabelle

Nach der Genehmigung des Projekts entwickelt die Entwicklungsabteilung das Projekt entsprechend den Anforderungen der Produktabteilung weiter.
Entwicklungsingenieure entwerfen die Tabellenstruktur zu Beginn des Entwicklungsprojekts. Für die Datenbank ist das Design der Tabellenstruktur sehr wichtig. Wenn es nicht richtig entworfen ist, wirkt sich dies direkt auf die Geschwindigkeit aus, mit der Benutzer auf die Website zugreifen, und das Benutzererlebnis wird schlecht sein! Es gibt viele spezifische Faktoren, die diese Situation beeinflussen, z. B. langsame Abfragen (ineffiziente Abfrageanweisungen), unsachgemäße Indizierung, Datenbanküberlastung (Sperren) usw. Natürlich gibt es in der Testabteilung ein Team, das Produkttests durchführt und Fehler findet.
Da sich Entwicklungsingenieure auf unterschiedliche Dinge konzentrieren, prüfen sie im Frühstadium nicht, ob das Datenbankdesign sinnvoll ist, sondern schließen die Funktionsimplementierung und -bereitstellung so schnell wie möglich ab. Sobald das Projekt online ist und ein bestimmtes Verkehrsaufkommen aufweist, werden versteckte Probleme aufgedeckt und es wird zu diesem Zeitpunkt nicht so einfach sein, sie zu ändern!

Phase 2: Datenbankbereitstellung

Es ist Zeit für den Betriebsingenieur, an Bord zu kommen und das Projekt zu starten.
In der frühen Phase eines Projekts ist die Anzahl der Besuche normalerweise sehr gering. In dieser Phase reicht eine einzelne Bereitstellung von Web+Datenbank aus, um etwa 1000 QPS (Abfragerate pro Sekunde) abzuwickeln. Unter Berücksichtigung einzelner Punktausfälle sollte eine hohe Verfügbarkeit erreicht werden. MySQL Master-Slave-Replikation + Keepalived kann verwendet werden, um Hot-Standby auf zwei Maschinen zu erreichen. Zur gängigen HA-Software gehören: Keepalived (empfohlen) und Heartbeat.

Phase 3: Optimierung der Datenbankleistung

Wenn MySQL auf einem normalen X86-Server eingesetzt wird, kann MySQL ohne Optimierung theoretisch etwa 1500 QPS verarbeiten. Nach der Optimierung kann dies auf etwa 2000 QPS gesteigert werden. Andernfalls kann die Datenbankverarbeitungsleistung langsam reagieren, wenn die Anzahl der Besuche etwa 1.500 gleichzeitige Verbindungen erreicht, und die Hardwareressourcen sind relativ reichlich vorhanden. Zu diesem Zeitpunkt ist es an der Zeit, Probleme bei der Leistungsoptimierung in Betracht zu ziehen. Wie können wir also die Leistung der Datenbank maximieren? Der Schwerpunkt liegt hauptsächlich auf der Hardwarekonfiguration, der Datenbankkonfiguration und der Architektur, die im Einzelnen wie folgt unterteilt sind:

3.1 Hardware-Konfiguration

Wenn die Bedingungen es zulassen, müssen Sie SSD-Solid-State-Laufwerke anstelle von mechanischen SAS-Festplatten verwenden und den RAID-Level auf RAID1+0 einstellen, das eine bessere Lese- und Schreibleistung als RAID1 und RAID5 bietet. Schließlich kommt der Druck auf die Datenbank hauptsächlich vom Festplatten-E/A.
Der Linux-Kernel verfügt über eine Funktion, mit der er den Cache-Bereich (Systemcache und Datencache) vom physischen Speicher trennt, um Hot Data zu speichern. Durch den verzögerten Schreibmechanismus des Dateisystems werden sie nur dann mit der Festplatte synchronisiert, wenn die Bedingungen erfüllt sind (z. B. wenn die Größe des Cache-Bereichs einen bestimmten Prozentsatz erreicht oder der Synchronisierungsbefehl ausgeführt wird). Das heißt: Je größer der physische Speicher, desto größer der zugewiesene Pufferbereich und desto mehr zwischengespeicherte Daten. Natürlich führt ein Serverausfall zum Verlust bestimmter zwischengespeicherter Daten. Es wird empfohlen, dass der physische Speicher mindestens 50 % überzählig ist.

3.2 Optimierung der Datenbankkonfiguration

In MySQL gibt es zwei am häufigsten verwendete Speicher-Engines: Eine davon ist MyISAM, das keine Transaktionsverarbeitung unterstützt, eine schnelle Leseleistung hat und Sperren auf Tabellenebene verwendet. Das andere ist InnoDB, das die Transaktionsverarbeitung (ACID-Eigenschaften) unterstützt und für die Verarbeitung großer Datenmengen und die Sperrung auf Zeilenebene konzipiert ist.
Tabellensperre: geringer Overhead, große Sperrgranularität, hohe Deadlock-Wahrscheinlichkeit und relativ geringe Parallelität.
Zeilensperre: hoher Overhead, geringe Sperrgranularität, geringe Deadlock-Wahrscheinlichkeit und hohe relative Parallelität.
Warum treten Tabellensperren und Zeilensperren auf? Hauptsächlich um die Datenintegrität sicherzustellen. Wenn beispielsweise ein Benutzer eine Tabelle bedient und andere Benutzer die Tabelle ebenfalls bedienen möchten, müssen sie warten, bis der erste Benutzer die Bedienung abgeschlossen hat, bevor andere Benutzer die Bedienung vornehmen können. Dies ist die Funktion von Tabellensperren und Zeilensperren. Andernfalls kommt es mit Sicherheit zu Datenkonflikten oder Anomalien, wenn mehrere Benutzer gleichzeitig eine Tabelle bedienen.
Aufgrund dieser Aspekte ist die Verwendung der InnoDB-Speicher-Engine die beste Wahl und zudem die Standard-Speicher-Engine für MySQL 5.5+. Jede Speicher-Engine verfügt über zahlreiche zugehörige Betriebsparameter. Im Folgenden sind die Parameter aufgeführt, die die Datenbankleistung beeinflussen können.
Standardwerte allgemeiner Parameter:

max_Verbindungen = 151
# Verarbeiten Sie die maximale Anzahl von Verbindungen gleichzeitig. Es wird empfohlen, die maximale Anzahl von Verbindungen auf etwa 80 % der Obergrenze der Verbindungen festzulegen. sort_buffer_size = 2M
# Es wird empfohlen, die Puffergröße bei der Abfrage der Sortierung, die nur für Order by und Group by funktioniert, auf 16 MB zu erhöhen.
Open_files_limit = 1024 
# Begrenzen Sie die Anzahl der geöffneten Dateien. Wenn der von show global status like 'open_files' angezeigte Wert gleich oder größer als der Wert von open_files_limit ist, kann das Programm keine Verbindung zur Datenbank herstellen oder friert ein.

Standardwerte der MyISAM-Parameter:

Schlüsselpuffergröße = 16 M
# Indexpuffergröße, im Allgemeinen auf 30–40 % des physischen Speichers eingestellt
Lesepuffergröße = 128 KB 
# Größe des Lesevorgangpuffers, es wird empfohlen, 16M oder 32M einzustellen
query_cache_type = EIN
# Abfrage-Cache-Funktion aktivieren query_cache_limit = 1M 
# Abfrage-Cache-Limit, nur Abfrageergebnisse unter 1 MB werden zwischengespeichert, um zu verhindern, dass die Ergebnisdaten den Cache-Pool überschreiben query_cache_size = 16 MB 
# Überprüfen Sie die Puffergröße, die zum Zwischenspeichern der SELECT-Abfrageergebnisse verwendet wird. Wenn dieselbe SELECT-Abfrage das nächste Mal ausgeführt wird, werden die Ergebnisse direkt aus dem Cache-Pool zurückgegeben. Sie können diesen Wert um ein Vielfaches erhöhen.

Standardwerte der InnoDB-Parameter:

innodb_buffer_pool_size = 128 M
# Index- und Datenpuffergröße, es wird empfohlen, sie auf etwa 70 % des physischen Speichers einzustellen innodb_buffer_pool_instances = 1  
# Anzahl der Pufferpoolinstanzen. Es wird empfohlen, 4 oder 8 festzulegen innodb_flush_log_at_trx_commit = 1 
# Schlüsselparameter. 0 bedeutet, dass das Protokoll etwa jede Sekunde geschrieben und auf die Festplatte synchronisiert wird. Ein Datenbankfehler führt zum Verlust von etwa 1 Sekunde Transaktionsdaten. 1. Nachdem jede SQL-Anweisung ausgeführt wurde, wird sie in das Protokoll geschrieben und mit der Festplatte synchronisiert. Dies hat einen großen E/A-Overhead. Nach der Ausführung der SQL-Anweisung müssen Sie warten, bis das Protokoll gelesen und geschrieben wurde, was ineffizient ist. 2 bedeutet, dass das Protokoll nur in den Systemcache geschrieben und dann jede Sekunde auf die Festplatte synchronisiert wird. Dies ist sehr effizient. Wenn der Server ausfällt, gehen die Transaktionsdaten verloren. Für diejenigen, die keine sehr hohen Anforderungen an die Datensicherheit stellen, wird Einstellung 2 empfohlen. Sie bietet eine hohe Leistung und der Effekt ist nach der Änderung offensichtlich.
innodb_file_per_table = AUS 
# Ob der Tablespace freigegeben werden soll. Die Standardeinstellung für Versionen 5.7+ ist EIN. Die IDBData-Datei im freigegebenen Tablespace wächst ständig, was die E/A-Leistung bis zu einem gewissen Grad beeinträchtigt. Es wird empfohlen, den unabhängigen Tablespace-Modus zu aktivieren. Der Index und die Daten jeder Tabelle werden in ihrem eigenen unabhängigen Tablespace gespeichert, sodass eine einzelne Tabelle zwischen verschiedenen Datenbanken verschoben werden kann.
innodb_log_buffer_size = 8M 
# Größe des Protokollpuffers. Da das Protokoll höchstens einmal pro Sekunde aktualisiert wird, muss es normalerweise nicht größer als 16 MB sein.

3.3 Optimierung der Systemkernelparameter

Die meisten MySQL-Server werden auf Linux-Systemen eingesetzt, daher wirken sich einige Parameter des Betriebssystems auch auf die MySQL-Leistung aus. Im Folgenden finden Sie eine entsprechende Optimierung der Linux-Kernel-Parameter.

net.ipv4.tcp_fin_timeout = 30
#TIME_WAIT-Timeout, der Standardwert beträgt 60 s
net.ipv4.tcp_tw_reuse = 1  
# 1 bedeutet, die Wiederverwendung zu aktivieren, sodass TIME_WAIT-Sockets für neue TCP-Verbindungen wiederverwendet werden können, 0 bedeutet, net.ipv4.tcp_tw_recycle = 1 zu deaktivieren.  
# 1 bedeutet, das schnelle Recycling von TIME_WAIT-Sockets zu aktivieren, 0 bedeutet, net.ipv4.tcp_max_tw_buckets = 4096 zu deaktivieren.  
# Das System behält die maximale Anzahl von TIME_WAIT-Sockets bei. Wenn diese Zahl überschritten wird, löscht das System zufällig einige TIME_WAIT und gibt eine Warnmeldung aus: net.ipv4.tcp_max_syn_backlog = 4096
# Geben Sie die maximale Länge der SYN-Warteschlange ein. Durch Erhöhen der Warteschlangenlänge können mehr wartende Verbindungen aufgenommen werden. Wenn in Linux-Systemen die Anzahl der von einem Prozess geöffneten Dateihandles den Systemstandardwert von 1024 überschreitet, wird die Meldung „zu viele Dateien geöffnet“ angezeigt. Daher muss das Limit für geöffnete Dateihandles angepasst werden.
Starten Sie neu, um es dauerhaft zu machen:
# vi /etc/security/limits.conf 
* Soft-Nofile 65535
* hartes Nofile 65535
Mit sofortiger Wirkung für den aktuellen Benutzer:
# ulimit -SHn 65535

Phase 4: Erweiterung der Datenbankarchitektur

Mit zunehmendem Geschäftsvolumen kann die Leistung eines einzelnen Datenbankservers die Geschäftsanforderungen nicht mehr erfüllen. Dann ist es an der Zeit, über die Hinzufügung einer Servererweiterungsarchitektur nachzudenken. Die Hauptidee besteht darin, die Last einer einzelnen Datenbank zu zerlegen, die Festplatten-E/A-Leistung zu durchbrechen, Hot Data im Cache zu speichern und die Häufigkeit des Festplatten-E/A-Zugriffs zu reduzieren.

4.1 Cache vergrößern

Fügen Sie der Datenbank ein Cache-System hinzu, um Hot Data im Speicher zwischenzuspeichern. Wenn sich die angeforderten Daten im Cache befinden, wird MySQL nicht mehr angefordert, wodurch die Datenbanklast verringert wird. Es gibt zwei Arten der Cache-Implementierung: lokaler Cache und verteilter Cache. Beim lokalen Cache werden Daten im lokalen Serverspeicher oder in einer Datei zwischengespeichert. Verteilter Cache kann große Datenmengen zwischenspeichern und ist gut skalierbar. Die gängigen verteilten Cachesysteme sind: Memcached und Redis. Memcached hat eine stabile Leistung, Daten werden im Speicher zwischengespeichert und die Geschwindigkeit ist sehr hoch. Die theoretische QPS kann etwa 80.000 erreichen. Wenn Sie Datenpersistenz wünschen, wählen Sie Redis. Die Leistung ist nicht geringer als bei Memcached.
Arbeitsprozess:

4.2 Master-Slave-Replikation und Lese-/Schreibtrennung

In einer Produktionsumgebung lesen Geschäftssysteme normalerweise mehr und schreiben weniger, sodass eine Master-Slave-Architektur eingesetzt werden kann. Die Master-Datenbank ist für Schreibvorgänge verantwortlich und führt einen Hot-Standby-Betrieb auf zwei Maschinen durch, und mehrere Slave-Datenbanken führen den Lastausgleich durch und sind für Lesevorgänge verantwortlich. Gängige Lastenausgleichsprogramme: LVS, HAProxy, Nginx.
Wie erreicht man eine Trennung von Lesen und Schreiben? Die meisten Unternehmen implementieren die Lese- und Schreibtrennung auf Codeebene, was äußerst effizient ist. Eine andere Methode besteht darin, die Lese- und Schreibtrennung durch ein Proxy-Programm zu erreichen. Dieses wird in Unternehmen weniger genutzt und erhöht den Middleware-Verbrauch. Zu den gängigen Middleware-Proxy-Systemen gehören MyCat, Atlas usw.
In dieser MySQL Master-Slave-Replikationstopologiearchitektur wird die Last einer einzelnen Maschine verteilt, was die Datenbank-Parallelitätsfähigkeit erheblich verbessert. Wenn ein Slave-Server 1500 QPS verarbeiten kann, dann können drei 4500 QPS verarbeiten und eine horizontale Skalierung ist problemlos möglich.
Bei Anwendungen mit einer großen Anzahl von Schreibvorgängen kann die Schreibleistung einer einzelnen Maschine manchmal nicht den geschäftlichen Anforderungen genügen. Sie können eine bidirektionale Replikation (Dual-Master) durchführen, dabei ist jedoch ein Problem zu beachten: Wenn beide Masterserver Lese- und Schreibvorgänge nach außen bereitstellen, kann es zu Dateninkonsistenzen kommen. Der Grund hierfür ist, dass das Programm wahrscheinlich zwei Datenbanken gleichzeitig betreibt. Die gleichzeitigen Aktualisierungsvorgänge führen zu Konflikten oder Inkonsistenzen in den Daten der beiden Datenbanken.
Sie können jedes Tabellen-ID-Feld auf automatische Inkrementierung und Eindeutigkeit einstellen: auto_increment_increment und auto_increment_offset, oder Sie können einen Algorithmus zum Generieren einer zufälligen eindeutigen Zahl schreiben.
Sie können auch den MGR-Cluster (Multi-Master-Replikation) in Betracht ziehen, der in den letzten zwei Jahren offiziell eingeführt wurde.

4.3 Datenbank-Sharding

Beim Datenbank-Sharding werden zusammengehörende Tabellen in der Datenbank je nach Geschäft in unterschiedliche Datenbanken aufgeteilt, z. B. Web-, BBS-, Blog- und andere Datenbanken. Bei einem großen Geschäftsvolumen kann die getrennte Datenbank als Master-Slave-Replikationsarchitektur verwendet werden, um eine übermäßige Belastung einer einzelnen Datenbank weiter zu vermeiden. 4.4 Untertabelle

Die Datenmenge nimmt dramatisch zu. Eine Tabelle in der Datenbank enthält Millionen von Daten, wodurch Abfragen und Einfügen zu lange dauern. Wie können wir den Druck einer einzelnen Tabelle lösen? Sie sollten erwägen, diese Tabelle in mehrere kleine Tabellen aufzuteilen, um den Druck auf eine einzelne Tabelle zu verringern und die Verarbeitungseffizienz zu verbessern. Diese Methode wird als Tabellen-Sharding bezeichnet.
Die Technologie des Tabellen-Shardings ist komplizierter. Sie erfordert die Änderung der SQL-Anweisungen im Programmcode und das manuelle Erstellen anderer Tabellen. Sie können zum Implementieren des Tabellen-Shardings auch die Merge-Storage-Engine verwenden, was relativ einfach ist. Nachdem die Tabellen aufgeteilt wurden, bearbeitet das Programm eine Mastertabelle. Diese Mastertabelle speichert keine Daten, sondern nur einige Beziehungen zwischen den Untertabellen und die Methode zum Aktualisieren der Daten. Die Mastertabelle verteilt den Druck je nach Abfrage auf verschiedene kleine Tabellen und verbessert dadurch die Parallelität und die Festplatten-E/A-Leistung.
Die Split-Tabelle ist in vertikale und horizontale Splits unterteilt:
Vertikale Aufteilung: Teilen Sie die Originaltabelle mit vielen Feldern in mehrere Tabellen auf, um das Problem der Tabellenbreite zu lösen. Sie können selten verwendete Felder in eine separate Tabelle einfügen, große Felder in eine separate Tabelle einfügen oder eng verwandte Felder in eine Tabelle einfügen.
Horizontale Aufteilung: Teilen Sie die Originaltabelle in mehrere Tabellen mit jeweils gleicher Struktur auf, um das Problem großer Datenmengen in einer einzelnen Tabelle zu lösen.

4.5 Partitionierung

Beim Partitionieren werden die Daten einer Tabelle entsprechend den Feldern in der Tabellenstruktur (wie Bereich, Liste, Hash usw.) in mehrere Blöcke aufgeteilt. Diese Blöcke können sich auf einer oder auf verschiedenen Festplatten befinden. Nach der Partitionierung ist es an der Oberfläche immer noch eine Tabelle, aber die Daten werden an mehreren Stellen gehasht. Auf diese Weise können mehrere Festplatten gleichzeitig unterschiedliche Anforderungen verarbeiten, wodurch die Lese- und Schreibleistung der Festplatten-E/A verbessert wird.
Hinweis: Das Hinzufügen von Cache, Unterbibliothek, Untertabelle und Partition wird hauptsächlich von Programmierern oder DBAs durchgeführt.

Phase 5: Datenbankwartung

Die Datenbankwartung ist die Aufgabe von Datenbankingenieuren oder Betriebs- und Wartungsingenieuren und umfasst die Systemüberwachung, Leistungsanalyse, Leistungsoptimierung, Datenbanksicherung und -wiederherstellung und andere wichtige Aufgaben.

5.1 Schlüsselindikatoren für den Leistungsstatus

Fachbegriffe: QPS (Queries Per Second) und TPS (Transactions Per Second)
Überprüfen Sie den Ausführungsstatus über „Status anzeigen“. Es werden mehr als 300 Statusinformationsdatensätze angezeigt, von denen einige Werte uns bei der Berechnung von QPS und TPS wie folgt helfen können:

Betriebszeit: Die tatsächliche Zeit, die der Server in Sekunden gelaufen ist
Fragen: Die Anzahl der Abfragen, die an die Datenbank gesendet wurden
Com_select: Anzahl der Abfragen, tatsächliche Datenbankoperationen
Com_insert: Anzahl der Einfügungen
Com_delete: Anzahl der Löschungen
Com_update: Anzahl der Aktualisierungen
Com_commit: Transaktionszeiten
Com_rollback: Anzahl der Rollbacks

Hier ist die Berechnungsmethode: Berechnen Sie QPS basierend auf Fragen

mysql> globalen Status wie „Fragen“ anzeigen;
mysql> globalen Status wie „Uptime“ anzeigen;
QPS = Fragen/Betriebszeit

Berechnen Sie TPS basierend auf Com_commit und Com_rollback:

mysql> globalen Status wie „Com_commit“ anzeigen;
mysql> globalen Status wie „Com_rollback“ anzeigen;
mysql> globalen Status wie „Uptime“ anzeigen;
TPS = (Com_commit + Com_rollback) / Betriebszeit

Eine andere Berechnungsmethode:

Berechnen Sie QPS basierend auf Com_select, Com_insert, Com_delete und Com_update:  
mysql> globalen Status anzeigen, wobei Variablenname in ('com_select', 'com_insert', 'com_delete', 'com_update'); ist.
Warten Sie 1 Sekunde und führen Sie den Vorgang erneut aus, um die Intervalldifferenz zu ermitteln. Der QPS ist der Wert jeder Variablen beim zweiten Mal abzüglich des entsprechenden Variablenwerts beim ersten Mal.

TPS-Berechnungsmethode:

mysql> globalen Status anzeigen, wobei Variablenname in ('com_insert', 'com_delete', 'com_update'); ist.
Bei der Berechnung von TPS zählen wir die Abfragevorgänge nicht und müssen nur die vier Werte Einfügen, Löschen und Aktualisieren berechnen.

Nachdem Internetnutzer diese beiden Berechnungsmethoden getestet hatten, kamen sie zu dem Schluss, dass die Berechnung mit Fragen genauer ist, wenn die Datenbank viele MyISAM-Tabellen enthält. Wenn die Datenbank viele InnoDB-Tabellen enthält, ist es genauer, Com_* für die Berechnung zu verwenden.

5.2 Aktivieren Sie das Protokoll für langsame Abfragen

MySQL aktiviert langsame Abfrageprotokolle, um zu analysieren, welche SQL-Anweisungen langsam sind. Dynamisches Aktivieren wird unterstützt:

mysql> globales Slow-Query-Log festlegen = ein 
# Langsame Abfrage aktivieren logmysql> set global slow_query_log_file='/var/log/mysql/mysql-slow.log'; 
# Geben Sie den Speicherort der Protokolldatei für langsame Abfragen anmysql> set global log_queries_not_using_indexes=on;  
# Abfragen aufzeichnen, die keine Indizes verwendenmysql> set global long_query_time=1;  
# Zeichnen Sie nur langsame Abfragen mit einer Verarbeitungszeit von mehr als 1 Sekunde auf. Zum Analysieren langsamer Abfrageprotokolle können Sie das mit MySQL gelieferte Tool mysqldumpslow verwenden. Die analysierten Protokolle sind relativ einfach.
mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log  
# Um die drei langsamsten Abfragen anzuzeigen, können Sie auch das Tool pt-query-digest von Percona verwenden, das über umfassende Protokollanalysefunktionen verfügt und langsame Protokolle, Binärprotokolle und allgemeine Protokolle analysieren kann.
Analysieren Sie das langsame Abfrageprotokoll: pt-query-digest /var/log/mysql/mysql-slow.log
Binlog-Protokoll analysieren: mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql 
pt-query-digest --type=binlog mysql-bin.000001.sql 
Allgemeine Protokolle analysieren: pt-query-digest --type=genlog localhost.log

5.3 Datenbanksicherung

Das Sichern der Datenbank ist die grundlegendste und wichtigste Aufgabe, denn sonst sind die Folgen schwerwiegend, wissen Sie! Bei hochfrequenten Backup-Strategien ist die Wahl eines stabilen und schnellen Tools von entscheidender Bedeutung. Wenn die Datenbankgröße weniger als 2 GB beträgt, wird die Verwendung des offiziellen logischen Sicherungstools mysqldump empfohlen. Wenn die Größe über 2 GB liegt, empfiehlt sich die Verwendung des physischen Sicherungstools xtrabackup von Percona, da es sonst langsam wie eine Schnecke ist. Beide Tools unterstützen Hot-Standby unter der InnoDB-Speicher-Engine, ohne geschäftliche Lese- und Schreibvorgänge zu beeinträchtigen.

5.4 Datenbankreparatur

Manchmal wird der MySQL-Server plötzlich mit Strom versorgt oder unnormal heruntergefahren, was zu Tabellenbeschädigungen führen und das Lesen von Tabellendaten unmöglich machen kann. Derzeit können Sie zur Reparatur die beiden mit MySQL gelieferten Tools myisamchk und mysqlcheck verwenden. Ersteres kann nur MyISAM-Tabellen reparieren und die Datenbank stoppen, während Letzteres sowohl MyISAM- als auch InnoDB-Tabellen online reparieren kann.
Hinweis: Am besten sichern Sie die Datenbank vor der Reparatur.

Allgemeine Parameter von myisamchk:
 -f --force Reparatur erzwingen, alte temporäre Dateien überschreiben, im Allgemeinen nicht verwendet -r --recover Wiederherstellungsmodus -q --quik Schnelle Wiederherstellung -a --analyze Tabelle analysieren -o --safe-recover Alter Wiederherstellungsmodus, wenn -r nicht reparieren kann, können Sie diesen Parameter ausprobieren -F --fast Überprüfen Sie nur Tabellen, die nicht normal geschlossen sind. Beispiel: myisamchk -r -q *.MYI

Allgemeine Parameter von mysqlcheck:
 -a --all-databases Alle Datenbanken prüfen -r --repair Tabelle reparieren -c --check Tabelle prüfen, Standardoption -a --analyze Tabelle analysieren -o --optimize Tabelle optimieren -q --quik Schnellste Prüfung oder Reparatur der Tabelle -F --fast Nur Tabellen prüfen, die nicht normal geschlossen werden. Beispiel: mysqlcheck -r -q -uroot -p123456 weibo

5.5 MySQL Server-Leistungsanalyse

Fokus:
id: Prozentuale CPU-Auslastung. Ein Durchschnitt von weniger als 60 % ist normal, aber es ist schon ziemlich viel los.
wa: CPU-Wartezeit für Disk-IO-Antwort. Im Allgemeinen weist ein Wert größer als 5 auf eine große Menge an Lese- und Schreibverkehr auf der Festplatte hin.

KB_read/s, KB_wrtn/s Die Menge der pro Sekunde gelesenen und geschriebenen Daten, hauptsächlich ausgewertet basierend auf der maximalen Lese- und Schreibgeschwindigkeit der Festplatte pro Sekunde.

r/s, w/s: Die Anzahl der Lese- und Schreibanforderungen pro Sekunde, die als IOPS (Input und Output pro Sekunde) verstanden werden kann, ist einer der Hauptindikatoren zur Messung der Festplattenleistung.
warten: Durchschnittliche IO-Antwortzeit pro Sekunde. Wenn sie größer als 5 ist, bedeutet dies, dass die Festplattenantwort langsam ist und ihre eigene Leistung übersteigt.
util: Prozentuale Festplattenauslastung. Ein Durchschnitt von weniger als 60 % ist normal, aber es ist schon ziemlich viel los.

Zusammenfassung

Aufgrund der ursprünglichen Designbeschränkungen relationaler Datenbanken sind sie nicht für die Verarbeitung großer Datenmengen geeignet. Daher ist NoSQL (nicht-relationale Datenbank) populär geworden. Es ist von Natur aus inspirierend und verfügt über die Eigenschaften der Verteilung, hohen Leistung und hohen Zuverlässigkeit. Es gleicht bestimmte inhärente Mängel relationaler Datenbanken aus und eignet sich sehr gut zum Speichern unstrukturierter Daten. Zu den gängigen NoSQL-Datenbanken gehören: MongoDB, HBase, Cassandra usw.

Die Verbesserung des Optimierungseffekts allein auf Datenbankebene ist nicht sehr offensichtlich. Es ist hauptsächlich erforderlich, die geeignete Datenbank entsprechend dem Geschäftsszenario auszuwählen!

Dies ist das Ende dieses Artikels zum einfachen Verständnis von MySQL-Datenbankoptimierungstechniken. Weitere relevante MySQL-Datenbankoptimierungstechniken finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!