Datenbankdesign und -optimierung

Den meisten langsamen Datenbanken fehlt der offensichtliche Index

Wenn eine Anwendung mit dem Wachstum langsamer wird, liegt die Ursache meist nicht am Server oder an der Datenbank-Engine. Es sind einige wenige Abfragen, die ganze Tabellen durchsuchen, weil kein Index zu ihrer Suchweise passt. Eine Abfrage, die bei 1.000 Zeilen 20 Millisekunden brauchte, kann bei einer Million Sekunden dauern, und niemand merkt es, bis die Kunden es merken.

Wir starten mit Belegen: den eigenen Statistiken der Datenbank darüber, welche Abfragen am häufigsten laufen und am längsten dauern. Das zeigt meist eine kurze Liste von Korrekturen, etwa einen Index auf den Spalten, die ein häufiger Filter nutzt, eine umgeschriebene Abfrage, die das Laden ganzer Tabellen vermeidet, oder eine fehlende Verknüpfung zwischen Tabellen, die wiederholte Lookups erzwingt. Wir messen jede Abfrage vorher und nachher, damit die Verbesserung sichtbar ist statt nur behauptet.

Constraints stoppen schlechte Daten an der Tür

Viele Datenbanken verlassen sich darauf, dass die Anwendung die Daten sauber hält. Die App prüft, dass eine E-Mail eindeutig ist, dass eine Bestellung zu einem echten Kunden gehört, dass eine Menge nicht negativ ist. Dann überspringt eine zweite App, ein Importskript oder eine eilige manuelle Korrektur diese Prüfungen, und Duplikate und verwaiste Datensätze schleichen sich ein. Berichte beginnen sich zu widersprechen, und niemand weiß, welche Zahl stimmt.

Ein gut entworfenes Schema erzwingt die wichtigen Regeln von selbst: eindeutige Constraints, Fremdschlüssel, Check-Constraints und sinnvolle Standardwerte. Alles, was in die Datenbank schreibt, muss sie einhalten. Bei einem bestehenden System finden wir heraus, wo Daten bereits fehlerhaft sind, planen die Bereinigung und ergänzen dann die Constraints, damit es nicht wieder passiert.

• Eindeutige Einschränkungen bei Dingen, die sich nicht wiederholen dürfen, wie E-Mails oder Rechnungsnummern
• Fremdschlüssel, damit Datensätze nicht auf etwas zeigen können, das nicht existiert
• Constraints prüfen für Werte, die im Bereich bleiben müssen
• Indizes aus echten Abfragemustern gewählt, nicht überall hinzugefügt