Performance-Optimierung in MySQL

MySQL ist ein Datenbankmanagement-Systen (DBMS), das zweifellos für betriebskritische Anwendungen konzipiert und entwickelt wurde, die Leistungsfähigkeit und Zuverlässigkeit dafür sind gegeben. Die Autoren von MySQL verzichteten dafür von vornherein lieber auf seltener genutzte Features, unter denen die Performance möglicherweise leiden könnte. MySQL[1] ist deshalb bis heute kein vollständiges DBMS, bewegt sich jedoch mit großen Schritten auf dieses Ziel zu.

Ab Version 4.0 gibt es neue Tabellentypen, die Transaktionen nach dem ACID-Prinzip[2] ermöglichen. In MySQL Server 4.0 legt das neue ».frm«-Dateiformat für Tabellendefinitionen intern bereits die Grundlage für neue Features, die in der Version 4.1 enthalten sind. Sie ist derzeit in einer Betaversion verfügbar. Dazu gehören unter anderem Subselects oder der Replikationsmechanismus. Für die nachfolgende Version 5.0 ist auch die Unterstützung von Stored Procedures, Triggers sowie referenzieller Integrität von Fremdschlüsseln (Foreign Keys) versprochen.

Trifft man in der Praxis auf langsame MySQL-Anwendungen, dann sind die Ursachen meist hausgemacht: ein schlechtes Datenbankdesign, ineffiziente Abfragen, Verzicht auf Indizierungen, eine schlechte Konfiguration oder unpassende Hardware-Ausstattung. Das alles ist vermeidbar. Die Performance-Optimierung sollte aber möglichst schon während der Entwicklung erfolgen und nicht erst als Nachbesserung am fertigen Produkt, denn je komplexer eine Anwendung ist, desto schwieriger wird die nachträgliche Optimierung.

Raum für Optimierungen

Bei MySQL-Datenbanken gibt es Optimierungsbedarf vor allem unter zwei Gesichtspunkten: Sind einzelne Queries zu langsam, ist fast immer ein suboptimales Design der Tabellen oder Queries die Ursache. Für Abhilfe sorgt in diesen Fällen: Ein Slow-Query-Log schreiben, langsame Queries identifizieren und mit »explain« analysieren. Wirkt jedoch die Datenbank als Ganzes lahm, liegt das meist an der Hardware oder an Versäumnissen bei der Installation.

Den Grundstein für gute Performance wird schon sehr früh gelegt, nämlich bereits beim Entwurf des Datenmodells auf Basis des Entity-Relationship-Modells (ERM)[2]. In der Praxis geht es dabei immer darum, einen Mittelweg zwischen strenger Normalisierung einerseits und schnellen, einfachen Modellen andererseits zu finden. Ein zu akademischer Ansatz führt im Allgemeinen zu einer hohen Anzahl von Tabellen und damit automatisch zu komplexen Abfragen, was die Datenbank deutlich verlangsamen kann.

Andererseits verhindert ein strenger Ansatz Redundanzen und damit die Gefahr von Inkonsistenz. Außerdem bleibt die Applikation besser anpassbar. Wenn Geschwindigkeitsprobleme auftreten, kann es sinnvoll sein, die Datenbank nachträglich zu denormalisieren. Aber erst nachdem die Ursachen gefunden und die möglichen Konsequenzen abgeschätzt wurden, lassen sich Rückschlüsse für die Wartung ziehen.

Welches Tabellenformat für welchen Zweck

In MySQL kommen zahlreiche Tabellenformate für die verschiedensten Einsatzzwecke und Umstände zum Einsatz[3]. Man unterscheidet zwischen Transaktions-basierten (InnoDB, BDB, Gemini) und nicht Transaktions-basierten (MyISAM, ISAM, HEAP, MERGE) Formaten. InnoDB, Gemini und BDB sollten dann eingesetzt werden, wenn die Konsistenz der Datenbank auf keinen Fall gefährdet werden darf. Die Daten können nach einem Absturz von MySQL automatisch wiederhergestellt werden. Zugleich stellen Transaktionen sicher, dass nicht mehrere Anwender simultan Datensätze verändern, und sichern damit die Integrität der Datenbank.

Verknüpfte Tabellen verweisen nur auf tatsächlich existierende Datensätze und nicht ins Leere. Transaktions-sichere Tabellen sind aber langsamer als das am häufigsten verwendete MyISAM-Format. Noch schneller als diese sind Heap Tables, die vollständig im Speicher residieren, aber nach einem Absturz oder Reboot natürlich verschwunden sind und sich deshalb nur für eine temporäre Datenhaltung eigen.