my.cnf-Parameterkonfiguration zur Optimierung der InnoDB-Engine-Leistung

Ich habe im Internet unzählige my.cnf-Konfigurationen gelesen und die meisten der erwähnten Konfigurationen sind nichts weiter als diese:

1. innodb_buffer_pool_size
2. innodb_log_file_size
3. innodb_log_buffer_size
4. innodb_flush_log_at_trx_commit

Dann habe ich zwei Beispiele geschrieben, eines mit einem Thread und eines mit mehreren Threads, um zu testen, ob die Leistung durch die Änderung der Konfigurationsparameter verbessert wurde. Das Ergebnis zeigt, dass nur innodb_flush_log_at_trx_commit die Leistung verbessern kann. Für die Parameter 1, 2 und 3 gilt: Unabhängig davon, ob einer davon aktiviert ist oder alle drei gleichzeitig angepasst werden, wird die Testleistung nicht beeinträchtigt. Ich habe darüber nachgedacht und es könnte daran liegen, dass die Menge meiner Testdaten nicht groß genug war. Ich werde diese drei Parameter mit einer größeren Datenmenge testen, wenn die Bedingungen es erlauben.

Hier ist eine detaillierte Beschreibung von innodb_flush_log_at_trx_commit:

Wenn innodb_flush_log_at_trx_commit auf 0 gesetzt ist, wird der Protokollpuffer einmal pro Sekunde in die Protokolldatei geschrieben und gleichzeitig der Flush-Vorgang (Auf Festplatte löschen) der Protokolldatei ausgeführt. In diesem Modus wird beim Festschreiben einer Transaktion der Schreibvorgang auf die Festplatte nicht aktiv ausgelöst.
Wenn innodb_flush_log_at_trx_commit auf 1 gesetzt ist, schreibt MySQL die Daten im Protokollpuffer in die Protokolldatei und schreibt sie bei jedem Commit einer Transaktion auf die Festplatte.
Wenn innodb_flush_log_at_trx_commit auf 2 gesetzt ist, schreibt MySQL bei jedem Commit einer Transaktion die Protokollpufferdaten in die Protokolldatei. Der Spülvorgang erfolgt jedoch nicht gleichzeitig. In diesem Modus führt MySQL einmal pro Sekunde einen Flush-Vorgang durch.

Ergebnis :

Wenn der Wert auf 0 gesetzt ist, ist dieser Modus der schnellste, aber weniger sicher. Ein Absturz des mysqld-Prozesses führt in der letzten Sekunde zum Verlust aller Transaktionsdaten.
Bei der Einstellung 1 ist dieser Modus der sicherste, aber auch der langsamste. Im Falle eines Absturzes des MySQL-Diensts oder des Serverhosts kann im Binärprotokoll höchstens eine Anweisung oder eine Transaktion verloren gehen.
Wenn der Wert auf 2 eingestellt ist, ist dieser Modus schneller und sicherer als 0. Alle Transaktionsdaten in der letzten Sekunde können nur verloren gehen, wenn das Betriebssystem abstürzt oder das System keinen Strom mehr hat.

Hinweis : Aufgrund von Problemen bei der Prozessplanung kann nicht garantiert werden, dass dieser „Spülvorgang einmal pro Sekunde“ zu 100 % „pro Sekunde“ erfolgt.

Fazit : Die Geschwindigkeit ist ähnlich, wenn innodb_flush_log_at_trx_commit auf 0 oder 2 gesetzt ist, und beide sind viel schneller, als wenn es auf 1 gesetzt ist.

Dies erinnert mich an den Unterschied zwischen InnoDB- und MyISAM-Engines. Der Vorteil von InnoDB besteht darin, dass es bei gleichzeitiger Verarbeitung schneller ist als MyISAM. Die Anzahl meiner Thread-Pools wird entsprechend der Anzahl der CPU-Threads festgelegt. Dann habe ich die Anzahl der Thread-Pools so eingestellt, dass sie größer, größer und größer als die Anzahl der CPU-Threads ist. Dadurch verbesserte sich die Leistung meines Testprogramms erneut. Ich war betrunken. Es stellte sich heraus, dass mein Verständnis von Thread-Pools zu oberflächlich war. Optimale Thread-Pool-Größe