MySQL Performance Serie – Addon: Analyze Table

von Bernd Erk | Nov 24, 2008 | MySQL, Serien

Im MySQL-Umfeld gibt es, wie in unsere Performance-Serie ausführlich geschildert, eine Vielzahl an Stellschrauben zur Optimierung.
Ein ganz wichtiger Punkte zur Optimierung von Joined-Selects ist die regelmässige Pflege der der internen Datenbankstatistiken. Hierfür gibt es den Befehl Analyze Table, welcher die Tabelleninhalte analysiert und entsprechende Statistiken über die Schlüsselverteilung speichert.
Der Befehl „show index from table“ ermöglicht einen Blick auf die aktuellen Statistiken und die entsprechende Index-Kardinalität. Kardinalität ist quasi der „Grad“ der Eindeutigkeit eines bestimmten Tabellenattributs. So sollte z. B. die Kardinalität eines Unique-Key-Attributes nach Aktualisierung durch Analyse Table der Menge der vorhandenen Rows entsprechen.
Diese Statistiken sind für die Datenbank extrem wichtig, um bei verknüpften Abfragen den „richtigen Weg“ zur Verringerung der zu verarbeitenden Daten einzuschlagen. Auch wenn der Explain-Befehl vermuten lässt, dass ein angelegter Index nicht verwendet, kann ein Analyze hier Abhilfe schaffen.
Wichtig ist, dass ein Analyze Table einen entsprechenden Lock der Tabelle zur Folge hat und über das Binlog auch in Replikationsumgebungen verteilt wird.

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

MySQL Performance Serie – Teil 8: Replikation

von Bernd Erk | Okt 8, 2008 | MySQL, Serien

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 lesen…

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

MySQL Performance Serie – Teil 7: Table-Partitioning

von Bernd Erk | Okt 1, 2008 | Serien, MySQL

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

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

MySQL Performance Serie – Teil 6: Slow-Query-Log

von Bernd Erk | Sep 24, 2008 | MySQL, Serien

Vielen MySQL-Benutzern ist der Slow-Query-Log natürlich bekannt und meistens die erste Anlaufstelle um langsame SQL-Queries im System aufzuspüren und in der Einzelanalyse zu optimieren. Interessant sind jedoch die Möglichkeiten die long_query_time, also die Zeit bis zur Ausführung des Statements, zu parametrisieren und die Statements auszugeben, die nicht von einem Index gebrauch machen. Wichtig ist jedoch immer eine längerfristige Beobachtung und Analyse des Systems um Unschärfen oder einmalige „Ausrutscher“ zu eliminieren und keine vorzeitigen Schlüsse zu ziehen.
Beim Start des MySQL-Daemons mit dem Parameter „–log-queries-not-using-indexes“ werden Statements ohne Verwendung von Indizes ebenfalls protokolliert. Die Anlage des richtigen Indizes ist neben der Aktivierung des Query-Caches meist die einfachste Möglichkeit die Selektionsperformance deutlich zu verbessern.
Zusätzlich kann der Datenbank-Administrator noch seine eigenen Langläufer mit dem Parameter „–log-slow-admin-statements“ ausgeben.
Inhalt des nächsten Serienteils ist das Table-Partioning.

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team

MySQL Performance Serie – Teil 5: Key-Buffer

von Bernd Erk | Sep 17, 2008 | MySQL, Serien

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

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 startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er 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 seinen beiden Söhnen und seiner Tochter.

Lies mehr von Bernd und triff unser Team