Indizes in MariaDB/MySQL: Viel hilft selten viel
Indizes. Jeder weiß, sie sind wichtig. Kaum jemand prüft regelmäßig, ob sie noch passen. In der Theorie machen sie Queries schnell. In der Praxis? Oft das Gegenteil, wenn planlos drauflos indiziert wird.
Beispiel aus dem echten Leben: Ein Shop mit einer halben Million Produkten. Für die Kategorie-Suche kamen zahlreiche zusätzliche Indizes ins Feld. Folge: Preisänderungen zogen sich wie Kaugummi. Erst als EXPLAIN die ungenutzten Indizes offenbarte und radikal aufgeräumt wurde, war der Spuk vorbei. Merke: Jeder Index muss beim Schreiben gepflegt werden. Bei viel Traffic oder vielen Updates bremst das mehr aus, als man denkt.
Seit MariaDB 10.3 gibt es ein paar Verbesserungen bei Full-Text- und Geo-Indizes. Full-Text lohnt sich aber erst ab ordentlichen Textbergen – bei kleinen Tabellen reicht meist ein banales LIKE. Alles andere ist nur Overhead.
Langsame Queries: Finden – nicht raten
Träge Abfragen machen Anwendungen zäh. Das Slow Query Log schafft Klarheit. Schwellenwert mal radikal auf 1 Sekunde oder weniger setzen, schon fallen auch die kleinen Dauerbremser auf. Aber: Das Log kostet Performance. Also gezielt aktivieren. Auswerten geht fix mit pt-query-digest vom Percona Toolkit. Da sieht man sofort, was wirklich lahmt und wie oft.
Typische Ursachen, immer wieder gesehen:
- Indizes fehlen oder sind Quatsch
- Joins über große Tabellen ohne gescheite Bedingungen
- Keine Limits, zu breite Unterabfragen
- Funktionen im WHERE, die Indizes aushebeln (Klassiker)
Kundendaten-Suche als Beispiel: Durch eine Funktion im WHERE wurde der Index auf dem Datum ignoriert. Nach Anpassen auf einen zusammengesetzten Index war die Antwortzeit plötzlich von 5 auf 0,1 Sekunden runter. Passiert öfter, als man glaubt.
Backups: Theorie kennt jeder – Praxis meist nicht
Backup. Pflicht. Gibt aber keinen Workflow, der für alle passt. Mysqldump reicht oft bei kleinen bis mittleren Datenbanken. Wird es größer, dauert der Dump ewig – und je nach Engine steht die Welt still. MyISAM? Komplett gesperrt. InnoDB geht mit --single-transaction, aber nur, wenn alles InnoDB ist.
Für große Systeme oder wenn Ausfallzeit Gift ist: Physische Backups, z. B. Percona XtraBackup. Damit sind Hot Backups und inkrementelle Sicherungen drin. Spart Zeit, Speicher und Nerven – aber auch nur, wenn Restore klappt.
Und jetzt der Killer: Backups werden fast nie getestet. Erst im Ernstfall kommt das böse Erwachen. Automatisierte Pläne mit Restore-Checks gehören fest eingebaut, egal ob Riesen-DB oder kleines Nebenprojekt. Sonst kann man’s auch gleich lassen.
30 Jahre Webentwicklung: Aus Schaden klüger
Drei Dinge, die sich nie ändern – Indizes, langsame Queries, Backup-Pannen. Seit den 90ern immer wieder das gleiche Spiel. Ein paar Beobachtungen aus Agentur- und Hosting-Alltag:
- Indizes müssen bei jedem Relaunch und bei wachsenden Datenmengen auf den Prüfstand. Wer das vergisst, wird garantiert später mit Support-Anrufen und Ladezeiten bestraft.
- Das Slow Query Log regelmäßig laufen lassen. Nicht erst, wenn der Kunde nachfragt, warum alles so zäh ist.
- Backups müssen nicht nur existieren, sondern auch im Notfall funktionieren. In kleinen Agenturen (5–10 Leute) sollten Restore-Tests Pflicht sein, bei Einzelkämpfern wenigstens ab und zu mal ein Dump zurückspielen – sonst ist der Tag irgendwann komplett ruiniert.
Wer diese Basics ignoriert, schaufelt sich sein Support-Grab meist selbst. Die meisten Fehler lassen sich mit ein bisschen Hausarbeit vermeiden. Spart Nerven und Wochenenden.
Fazit
Ohne gepflegte Indizes, Query-Checks und brauchbare Backups läuft mit MariaDB/MySQL früher oder später nichts mehr rund. Wer sich das als Routine angewöhnt, muss sich bei Datenverlust und Performance nicht jedes Mal wundern.
bye
mo
Zuletzt bearbeitet: