MySQL my.cnf-Tuning: Leitfaden für Performance-Einstellungen

Auf einem Gameserver oder einer stark frequentierten Webanwendung ist der Engpass oft nicht MySQL selbst, sondern die Tatsache, dass es noch mit den Standardeinstellungen läuft. Das Abstimmen deiner MySQL my.cnf-Datei ist der günstigste Performance-Gewinn, den du ohne neue Hardware erzielen kannst. In dieser Anleitung gehe ich die Parameter durch, die wirklich einen Unterschied machen — vom InnoDB Buffer Pool über Verbindungslimits bis zu Log-Einstellungen und Query-Caching — und erkläre, warum jeder davon zählt.

Wo liegt my.cnf und wie funktioniert sie?

MySQL (und MariaDB) lesen ihre Konfiguration beim Start aus mehreren Dateien. Unter Linux sind die häufigsten Pfade:

• /etc/my.cnf
• /etc/mysql/my.cnf
• /etc/mysql/mysql.conf.d/mysqld.cnf (Debian/Ubuntu)
• /etc/my.cnf.d/*.cnf (CentOS/Alma/Rocky)

Um zu sehen, welche Dateien in welcher Reihenfolge gelesen werden, führe aus:

mysqld --verbose --help | grep -A1 "Default options"

Die Einstellungen kommen unter den Abschnitt [mysqld]. Nach jeder Änderung musst du den Dienst neu starten:

sudo systemctl restart mysql   # oder mariadb

InnoDB Buffer Pool: die kritischste Einstellung

Wenn du nur einen Parameter abstimmen dürftest, wäre es innodb_buffer_pool_size. InnoDB hält Daten und Indizes in diesem Speicherbereich; je größer er ist, desto mehr Lesezugriffe kommen aus dem RAM statt von der Festplatte. Die Faustregel lautet 50 bis 70 % des gesamten RAM auf einem dedizierten Datenbankserver. Teilen sich ein Gameserver, PHP oder andere Dienste dieselbe Maschine, sei vorsichtiger.

[mysqld]
innodb_buffer_pool_size = 4G
innodb_buffer_pool_instances = 4

Bei großen Pools (über 8 GB) kannst du den Pool auf mehrere Instanzen aufteilen, um interne Lock-Contention zu verringern; jede Instanz sollte idealerweise mindestens 1 GB groß sein. Um zu prüfen, ob der Pool ausreicht, sieh dir die Trefferquote an:

SHOW ENGINE INNODB STATUS\G

Liegt die Buffer pool hit rate in der Ausgabe nahe bei 1000/1000, kommen nahezu alle Lesezugriffe aus dem Speicher. Ist sie niedrig, ziehe eine Vergrößerung des Pools in Betracht.

InnoDB-Logs und Schreibverhalten auf die Festplatte

Bei schreiblastigen Workloads sind die Größe des Redo-Logs und die Flush-Strategie entscheidend. Ist innodb_log_file_size (in MySQL 8 auch über innodb_redo_log_capacity verwaltbar) zu klein, setzt MySQL ständig Checkpoints und die Schreibleistung bricht ein.

innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
innodb_flush_method = O_DIRECT

• innodb_flush_log_at_trx_commit = 1 bietet volle ACID-Sicherheit; jeder Commit wird auf die Festplatte geschrieben. Für Finanzdaten beibehalten.
• Der Wert 2 schreibt das Log einmal pro Sekunde auf die Festplatte; du gewinnst deutlich an Schreibdurchsatz, riskierst aber bei plötzlichem Stromausfall den Verlust der letzten ~1 Sekunde. Für unkritische Daten wie Game-Inventar ist das ein vertretbarer Kompromiss.
• O_DIRECT umgeht den Cache des Betriebssystems und verhindert doppeltes Puffern.

Verbindungseinstellungen: max_connections und der Thread-Cache

Wenn viele gleichzeitige Spieler oder Webanfragen eintreffen und max_connections zu niedrig ist, erhältst du den Fehler „Too many connections". Diesen Wert blind zu erhöhen ist aber ebenso riskant: Jede Verbindung verbraucht Speicher.

max_connections = 200
thread_cache_size = 32
wait_timeout = 120
interactive_timeout = 120

thread_cache_size verwendet die Threads geschlossener Verbindungen wieder und senkt so die Kosten für eine neue Verbindung. wait_timeout schließt inaktive Verbindungen, damit hängende Clients nicht dauerhaft einen Slot belegen. Nutzt deine Anwendung einen Connection Pool (zum Beispiel die persistenten Verbindungen von Laravel), stimme den Timeout entsprechend ab.

Query-Cache und Versionsunterschiede

Vorsicht bei query_cache_size, das in vielen alten Tutorials auftaucht: Der Query-Cache war in MySQL 5.7 standardmäßig deaktiviert und wurde in MySQL 8.0 vollständig entfernt, weil er bei hoher Parallelität Lock-Contention verursachte. Nutzt du MySQL 8 und fügst diese Zeilen in die my.cnf ein, startet der Dienst nicht. Der moderne Ansatz besteht darin, in der Anwendungsschicht (Redis, Memcached) zu cachen oder auf den InnoDB Buffer Pool zu setzen.

Blähe auch die Puffer pro Verbindung nicht auf; sie werden für jede Verbindung separat zugewiesen:

sort_buffer_size = 2M
join_buffer_size = 2M
tmp_table_size = 64M
max_heap_table_size = 64M

Änderungen überprüfen und messen

Werte einzustellen ist die halbe Arbeit; ihre Wirkung zu messen die andere Hälfte. Prüfe die aktiven Werte:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW GLOBAL STATUS LIKE 'Threads_connected';

Um langsame Abfragen aufzuspüren, aktiviere das Slow Query Log und finde die echten Engpässe:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Unter den fertigen Tools analysiert mysqltuner.pl einen laufenden Server und gibt konkrete Empfehlungen; wende sie jedoch nicht blind an — setze jede erst um, nachdem du verstanden hast, warum sie vorgeschlagen wird. Denk daran: Selbst die beste my.cnf rettet keine schlecht geschriebene Abfrage oder einen fehlenden Index. Korrigiere zuerst deine Abfragen und Indizes mit EXPLAIN und feinjustiere danach die Konfiguration.

Häufige Fragen

Muss ich MySQL für Änderungen an der my.cnf neu starten?

Für die meisten InnoDB-Einstellungen (Buffer Pool, Logdateigröße) ja. Viele Variablen lassen sich jedoch zur Laufzeit dynamisch mit SET GLOBAL ändern — zum Beispiel SET GLOBAL max_connections = 300;. Dynamische Änderungen gehen beim Neustart verloren; um sie dauerhaft zu machen, musst du sie trotzdem in die my.cnf schreiben.

Was passiert, wenn ich innodb_buffer_pool_size zu groß mache?

Du kannst den RAM erschöpfen und das Betriebssystem oder andere Dienste in den Swap drängen; dann ist die Leistung schlechter als mit einem kleinen Pool. Bedenke, dass neben dem Buffer Pool auch jede Verbindung Speicher belegt, und lass der Maschine insgesamt genug Spielraum.

Nutze ich MySQL oder MariaDB, und sind die Einstellungen gleich?

Die zentralen InnoDB- und Verbindungseinstellungen sind weitgehend gemeinsam. Dennoch gibt es Unterschiede beim Query-Cache, beim Thread-Pool und bei einigen Standardwerten. Nimm die Ausgabe von SHOW VARIABLES als Referenz, um die für deine Version gültigen Einstellungsnamen zu bestätigen.

Bremst deine Datenbank deinen Server aus? Wenn du Hilfe beim MySQL/MariaDB-Tuning, beim Index-Design oder bei der Query-Optimierung für einen Gameserver oder ein Webprojekt brauchst, nimm Kontakt mit mir auf — ich sehe mir deine aktuelle Konfiguration an und erstelle einen konkreten Verbesserungsplan.