Speed Optimierung für WordPress – Part 4: Drei Schritte zur MySQL Optimierung

Willkommen zu Teil Vier meiner kleinen Artikelreihe zur Optimierung von WordPress.
Heute möchte ich über meine persönlichen Erfahrungen mit der Optimierung von MySQL berichten.

Vorab: ehe man Optimierungen vornimmt, ist es immer eine gute Idee, ein Datenbank-Backup zu machen. Dafür gibt es diverse WordPress Plugins; alternativ schreibt man einfach sein eigenes kleines MySQL Backup Script und nötigt einen Cronjob mit dessen Ausführung. Da ich Euch hier nicht mit überflüssigen Zeilen erschlagen möchte, kann mein kleines MySQL Backup Script bei GitHub heruntergeladen werden.

Schritt Eins meiner MySQL Optimierung

Der Einsatz von mysqloptimize.
Auch dafür habe ich mir ein kleines Script geschrieben, welches einmal pro Woche über die komplette MySQL Datenbank (also über alle WordPress-Instanzen) läuft. Das Script könnt ihr hier downloaden.
Damit wird zuerst also sichergestellt, dass die MySQL Datenbank in einem konsistenten, einwandfreiem Zustand ist.

Schritt Zwei meiner MySQL Optimierung

Das Setzen der folgendden beiden WordPress Konstanten in der wp-config.php:

define('EMPTY_TRASH_DAYS', 10);
define('WP_POST_REVISIONS', false);

Die erste Konstante leert den Papierkorb nach 10 Tagen (eine „0“ an dieser Stelle deaktiviert den Papierkorb), die zweite Konstante sorgt dafür, dass die automatische Speicherung von Beiträgen deaktiviert wird.

Schritt Drei meiner MySQL Optimierung

Der Einsatz von „Tuning-Primer“.
Das ist ein Shell-Script, welches die MySQL Datenbank prüft, und nach der Prüfung wertvolle Hinweise zum (Fein-) Tuning der MySQL und MariaDB Datenbank gibt.
Man kann das Script hier auf Git downloaden.

Der Output des Scriptes gibt detaillierte Informationen, an welcher Stelle Optimierungsbedarf besteht.
Alle  Anpassungsvorschläge für die einzelnen MySQL Werte, müssen in der my.cnf gesetzt werden, da diese sonst nach dem Neustart der MySQL Datenbank verloren gehen.

Ein kleiner Hinweis an dieser Stelle: das TuningPrimer Script kann nur korrekte Werte ermitteln, wenn die MySQL Datenbank mehr als zwei Tage läuft.
Ehe man also nun hingeht, und Werte in der my.cnf ändert,  die Datenbank neu startet um danach wieder mindestens zwei Tage zu warten, ehe das TuningPrimer Script eine valide Aussage treffen kann …  es gibt eine Alternative 🙂

Diese Alternative lautet:  melde Dich auf der Konsole Deiner MySQL Datenbank an, und setzt die Werte, die man in der my.cnf angepasst hat zur Laufzeit.
Das geht ganz einfach mit dem „set“ Befehl.
Also z.B. setzt ‚ set GLOBAL table_open_cache=524288; ‚ den Wert table_open_cache auf 524288 Bytes.

Um eine Übersicht der MySQL Variablen zu bekommen, hilft ein  ‚ show variables; ‚ auf der MySQL Konsole.

Wichtig dabei ist:

• der User mit dem man sich in die MySQL einloggt, sollte die Rechte haben, diese Werte verändern zu dürfen 🙂
• Regemäßigkeit; die Daten in der MySQL Datenbank ändern sich ständig, gerade auf grösseren Blogs

So … das war schon alles. In Summe zwar ein wenig Arbeit, aber nicht wirklich „rocket science“ 🙂