Optimierung der MySQL-Speicherparameter

1. Schlüsselpuffer

A. Der Parameter key_buffer_size beeinflusst nur die Geschwindigkeit der Indexverarbeitung, insbesondere die Geschwindigkeit des Indexlesens;

C. Um zu beurteilen, ob dieser Parameter richtig eingestellt ist, können Sie die beiden Statuswerte überprüfen, z. B. „%key_read%“;

D stellt die Gesamtzahl der Anfragen dar , und key_reads stellt die Anzahl der Festplattenlesevorgänge dar;

E key_reads / key_read_requests sollte so niedrig wie möglich sein, mindestens 1:100, 1:1000 ist besser; Um die Größe von key_buffer_size zu schätzen, müssen Sie den Wert jeder Tabelle in Ihre Datenbank eingeben. Werfen wir einen Blick auf den gesamten von den Indizes belegten Speicherplatz.

2. Abfragecache

A. Der Abfragecache speichert hauptsächlich SELECT-Anweisungen und Abfrageergebnisse

B überprüft werden Status der Datenbank: Status wie „%qcache%“ anzeigen

C Der Parameter query_cache_type gibt an, ob der Abfragepuffer 1 verwendet werden soll.

E.

Qcache-Abfragen im Cache 12737 geben die Anzahl der derzeit zwischengespeicherten Elemente an

Qcache fügt 20649006 ein

Qcache trifft 79060095 Es scheint, dass die Rate wiederholter Abfragen ziemlich hoch ist

Qcache lowmem PRunes 617913 Es gab so viele Fälle, in denen der Cache zu niedrig war

Qcache nicht zwischengespeichert 189896 　

Qcache freier Speicher 18573912 Der aktuell verbleibende Cache-Speicherplatz

Qcache freie Blöcke 5328 Diese Zahl scheint etwas groß zu sein und enthält viele Fragmente

Qcache-Gesamtblöcke 30953

F Die Ergebnisse zeigen, dass der Abfrage-Cache-Wert größer eingestellt werden muss

G. Wenn der Wert sehr groß ist, bedeutet dies, dass sich viele Fragmente im Puffer befinden Gleichzeitig: Wenn der Wert von Qcache_hits sehr groß ist, bedeutet dies, dass der Abfragepuffer sehr häufig verwendet wird. Zu diesem Zeitpunkt muss die Puffergröße erhöht werden. Wenn der Wert von Qcache_hits klein ist, bedeutet dies, dass Ihre Abfrage wiederholt wird Die Rate ist sehr niedrig. In diesem Fall wirkt sich die Verwendung des Abfragepuffers auf die Effizienz aus. Dann können Sie in Betracht ziehen, keine Abfragepufferung zu verwenden. Darüber hinaus kann das Hinzufügen von SQL_NO_CACHE zur SELECT-Anweisung eindeutig darauf hinweisen, dass der Abfragepuffer nicht verwendet wird.

3. Tabellencache

A. table_cache gibt die Größe des Tabellencaches an.

B. Immer wenn MySQL auf eine Tabelle zugreift Durch die Überprüfung der Statuswerte „Open_tables“ und „Opened_tables“ zur Spitzenzeit kann festgestellt werden, ob die Tabelle geöffnet und darin platziert ist Der Wert von table_cache muss erhöht werden. Wenn Sie feststellen, dass open_tables gleich table_cache ist und open_tables ständig wächst, müssen Sie den Wert von table_cache erhöhen.

D Beachten Sie, dass table_cache nicht blind auf einen großen Wert gesetzt werden kann. Bei einer zu hohen Einstellung kann es zu unzureichenden Dateideskriptoren kommen, was zu instabiler Leistung oder Verbindungsfehlern führen kann.

4. Innodb-Puffer

A. Innodb-Tabellen reagieren empfindlicher auf Pufferung als MyISAM-Tabellen. MyISAM kann unter der Standardeinstellung „key_buffer_size“ gut laufen, aber Innodb läuft im Schneckentempo unter der Standardeinstellung „innodb_buffer_pool_size“.

B. Da Innodb sowohl Daten als auch Indizes zwischenspeichert, ist es nicht erforderlich, dem Betriebssystem zu viel MySQL-Datenbankspeicher zu überlassen. Wenn Sie also nur Innodb verwenden müssen, können Sie ihn auf bis zu 70-100 % festlegen. 80 % des verfügbaren Speichers.

C. Wenn Ihr Datenvolumen nicht groß ist und nicht dramatisch ansteigt, besteht keine Notwendigkeit, innodb_buffer_pool_size zu groß einzustellen.

D. innodb_log_file_size ist wichtig bei hoher Schreiblast, insbesondere bei großen Datensätzen. Je größer der Wert, desto besser die Leistung. Beachten Sie jedoch, dass sich die Wiederherstellungszeit verlängern kann. Normalerweise stelle ich es auf 64-512 MB ein, abhängig von der Servergröße. Die Standardeinstellung von innodb_log_buffer_size bietet eine akzeptable Serverleistung bei mäßiger Schreiblast und kurzen Transaktionen.

E. Liegt innodb_flush_logs_at_trx_commit daran, dass Innodb 1000-mal langsamer ist als MyISAM? Möglicherweise haben Sie vergessen, diesen Parameter zu ändern. Der Standardwert ist 1, was bedeutet, dass jede festgeschriebene Aktualisierungstransaktion (oder jede Anweisung außerhalb einer Transaktion) auf die Festplatte geschrieben wird, was sehr ressourcenintensiv ist, insbesondere ohne einen batteriegepufferten Cache. Für viele Anwendungen, insbesondere solche, die von MyISAM konvertiert wurden, reicht es aus, den Wert auf 2 zu setzen, was bedeutet, dass das Protokoll nicht auf die Festplatte, sondern nur in den Cache des Betriebssystems geschrieben wird. Das Protokoll wird weiterhin jede Sekunde auf die Festplatte geschrieben, sodass die Kosten für 1–2 Aktualisierungen pro Sekunde normalerweise nicht verloren gehen. Wenn es auf 0 gesetzt ist, ist es viel schneller, aber auch relativ unsicher. Einige Transaktionen gehen verloren, wenn der MySQL-Server abstürzt. Eine Einstellung von 2 führt dazu, dass der Teil der Transaktion, der in den Betriebssystem-Cache geleert wird, verloren geht.

Das Obige ist der Inhalt der MySQL-Speicherparameteroptimierung. Weitere verwandte Artikel finden Sie auf der chinesischen PHP-Website (www.php.cn).