MySQL Performance Serie – Zusammenfassung

Wie im letzten Post dieser Serie bereits versprochen, haben wir alle Themen der MySQL Performance Serie nochmals zusammengefasst um einen Überblick über alle erläuterten Themen zu geben.
Durch Feedback und Fragen unserer Leser ist die Serie dann doch etwas größer ausgefallen als erwartet, aber das kann eigentlich ja nur gut sein 😉

Nochmals vielen Dank an alle für das zahlreiche Feedback und das Interesse an dieser Serie.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 10: Überblick behalten

In vielen Teilen der Blog-Serie sind wir auf Möglichkeiten eingegangen, Probleme zu identifizieren und deren Ursache zu analysieren und zu eliminieren. Im täglichen Betrieb fehlt es jedoch meist an der Zeit Statusvariablen zu filtern, Ausführungspläne einzelner Statements zu durchforsten oder aktuelle Datenbankverbindungen zu tracen.
Eine große Erleichterung bieten hier Werkzeuge wie MyTop und InnoTop. Beide geben in einem topähnlichen Stil den aktuellen Status der Datenbank wieder und bieten Aufschluss über die aktuell laufenden Prozesse. InnoTop, der Name verrät es bereits, ist stärker auf die Parameter der InnoDB-Engine spezialisiert, welche sich in der Konsole auch mit dem Befehl “show engine innodb status” auswerten lassen.
Besonderes Merkmal von InnoTop ist die Möglichkeit sich auf mehrere Server gleichzeitig zu verbinden und diese zu Gruppen zusammenzufassen. So kann man auch in einer geclusterten Umgebung gut den Überblick behalten.
Vorerst ist dies der letzten Teil unserer Performance-Serie rund um MySQL, aber weitere Serien werden folgen. In den nächsten Tage wird es noch eine Zusammenfassung der einzelnen Artikel zum Abschluss geben.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 9: Verwendung von Indizes

Fehlende oder falsche Indizes sind ein häufiger Grund für eine schlechte Abfrageperformance. Mit Hilfe des Slow-Query-Logs lassen sich vorhandene Langläufer meist auch gut identifizieren, jedoch kommt dann natürlich die Frage des Warum?
Auskunft über den Query-Execution-Plan und die Verwendung von Indizes gibt der Befehl Explain.
Folgendes Beispiel zeigt die Ausgabe des Befehls

  • EXPLAIN SELECT name, strasse, land FROM adressen WHERE strasse= “hauptstrasse” and name = “Erk” ORDER BY strasse;

select_type: SIMPLE
table: adressen
type: ref
possible_keys: strasse, name
key: strasse
key_len: 150
ref: const
rows: 1229
Extra: Using where; Using filesort

Die Ausgabe des Explain-Befehls gibt Aufschluss über die vorhandenen (possible_keys) und verwendeten (key) Indizes. MySQL verwendet pro Tabelle in einer Query maximal einen Index und zwar den, mit der kleineren Treffermenge.
Im oben genannten Beispiel empfiehlt sich also möglicherweise die Anlage eines mehrspaltigen Indizes. Legt man das Sortierkrierium (in diesem Fall Strasse) noch an die letzte Stelle des Indizes, dann spart man sich zusätzlich noch den teuren Filesort da die Daten bereits sortiert im Index liegen.
Inhalt des nächsten und letzten Artikels dieser Serie ist das Thema “Überblick behalten”.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 8: Replikation

MySQL verfügt über einen guten Replikationsmechanismus, der bei korrekter Konfiguration sehr fehlerunanfällig und stabil seinen Dienst verrichtet.
Die Replikation einer Datenbank hat in der Regel eines der folgenden Motive:

  • Lastverteilung: Entweder über Multi-Master-Replikation oder Master-Slave durch gezielte Select-Zuweisung auf die Slave-Datenbanken
  • Ausfallsicherheit: Multi-Master-Replikation als Failover-Datenbank ohne manuellen Zugriff
  • Verwendung einer Slave-DB als Aggregations- und/oder Analysedatenbank.

Neu in der Version 5.1 ist die Mixed-Based Replikation (kurz MBR). Hier erfolgt die Replikation normalerweise Statement basierend und wird nur bei bestimmten Ausnahmen auf Row-Level Replikation umgestellt. In vielen Szenarien resultiert die Verwendung von MBR in einer erheblichen Performancesteigerung.
Ein bekanntes Problem bei der Multi-Master-Replikation ist die automatische Schlüsselvergabe. Die MySQL Parameter auto_increment_increment und auto_increment_offset vermeiden hier doppelte Schlüsselvergabe indem Sie eine Art Schlüsselband pro Replikationsknoten erzeugen.
(mehr …)

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 7: Table-Partitioning

Mit der Version 5.1 hält Table-Partitioning Einzug in MySQL. Kommerzielle Datenbanken wie z.B. Oracle haben schon seit Jahren dieses Feature implementiert und es wird wirklich Zeit dass MySQL hier nachzieht.
Partitioning zerlegt nach definierbaren Regeln eine physikalische Tabelle in einzelne Teile. Für den Anwender ist dies transparent und er bekommt bei normalen DDL nichts von den vorhandenen Partitionen mit. Die “Zerlegungsregel” kann bei Anlage der Tabelle mitgegeben und einzelne Partionen danach entfernt oder hinzugefügt werden.
Version 5.1 unterstützt MySQL folgende Partitionierungsstrategien:

  • List-Partitioning
  • Range-Partitioning
  • Hash-Partitioning
  • Key-Partitioning

Die Dokumentation gibt detailierten Aufschluss über die vorhandenen Optionen und das passende Einsatzszenario.
Besonders interessant ist noch das sogenannte Partition-Pruning. Hier kann die Datenbank einzelne Partitionen bei einer selektiven Abfrage mit Where-Klausel ausschliessen und somit die zu verarbeitende Menge minimieren.
Replikation ist Inhalt des nächsten Teils.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 5: Key-Buffer

Bei Verwendung der MyISAM-Storage Engine macht die Datenbank vom sogenannten Key-Buffer-Cache gebrauch. In diesem Cache werden die meist frequentierten Index-Blöcke, ähnlich wie beim Query-Cache, abgelegt um den langsameren Zugriff auf das Plattensubsystem zu vermeiden. Bei Nutzung von MyISAM ist die Verwendung dieses Speicherbereichs ein absolutus muss.
Desto näher die Key-Hit-Ratio an 100% ist, desto besser die Effektivität und daraus folgend die Performance. Mit folgender Formel lässt sich die Key-Hit-Ratio ermitteln:

  • 100 – (key_reads * 100 / key_read_requests)

Die Werte können mit dem Befehl “show global status” ermittelt werden. Besonders interessant ist noch die Möglichkeit hochfrequentierte Blöcke manuell in den Key-Buffer zu laden. Dieses sogenannte Index Preloading gibt dem Administrator eine gute Möglichkeit die Wirksamkeit zu ermitteln.
Schwerkpunkt des nächsten Teils ist das Thema Slow-Queries.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

MySQL Performance Serie – Teil 4: Query-Cache

Wie bereits im ersten Teil unserer Performance-Serie angesprochen, ist die schnellste Art der Ergebnissermittlung innerhalb der Datenbank der Query-Cache.
Mit dem Befehl “show variables like ‘query%’;” können die aktuellen Einstellungen zum Query-Cache ermittelt werden. Häufig ist der Wert des Parameters query_cache_type zwar auf ON jedoch die eigentliche query_cache_size auf 0 was die Cache quasi ausschaltet. Sobald dem Query-Cache eine gewisse Grösse an Hauptspeicher zugewiesen wird, was aufgrund des dynamischen Speichermanagements auch zur Laufzeit funktioniert, verrichtet er seinen Dienst und liefert bereits selektierte Ergebnismengen aus dem Speicher aus.
Mit dem Befehl “show status like ‘qc%’;” kann der aktuelle Status und die Auslastung des Query-Caches ermittelt werden. Auch der MySQl-Administrator bietet eine grafische Möglichkeit die Hitrate zu analysieren.
Thema des nächsten Teils ist der Key-Buffer.

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Blogvorstellung: MySQL Performance Blog

Man kann es fast nicht glauben, aber im MySQL Performance Blog geht es tatsächlich um MySQL und wie man dessen Performance steigert, höchstens ganz am Rande noch ein bisschen um PHP. Geschrieben wird das Blog von den Mitarbeitern der Firma Percona Inc., in der sich einige MySQL Experten und ehemalige MySQL Mitarbeiter tummeln und hauptsächlich MySQL Consulting anbieten. Die Artikel sind zum überwiegenden Teil technischer Natur und bieten einen sehr hohen Anteil an wirklich interessantem Wissen. Dazwischen gibt es Hinweise auf anstehende Konferenzen oder wo demnächst Vorträge gehalten werden. Beispielsweise ging es in letzter Zeit um einen Performancevergleich zwischen MySQL Replikation und DRBD, ob man Swap auf Datenbankservern besser deaktivierten sollte oder wie man am besten die MySQL Logs rotiert.
Die Kollegen posten alle 1 oder 2 Tage einen neuen Blogeintrag. Klar ist nicht jedes Posting für jeden Leser gleich interessant, aber in dem Bereich hohe Performance und große Installationen kenne ich keine anderen Blog der so viele Infos liefert. Egal ob man einen einzelnen DB Server noch weiter tunen oder die Replikation zwischen Master und 20 Slaves in den Griff kriegen will. Deswegen ist das MySQL Performance Blog ein absolutes Muss für jeden Feedreader.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.