Datenbankabfragen reduzieren und vereinfachen

Ein einziger Aufruf einer typischen CMS-Seite löst im Hintergrund Dutzende Datenbankabfragen aus. Beiträge, Einstellungen, Menüpunkte, Metadaten, dazu alles, was die eingebauten Erweiterungen noch wissen wollen. Und das für Inhalte, die zuletzt vor drei Wochen bearbeitet wurden. Bei jedem Besucher aufs Neue dieselbe Rechnung mit demselben Ergebnis.

Info

Die vier Erfolgskriterien von Guideline 3.16

Effiziente Datenbankabfragen: Optimiere Datenbankabfragen, um die Last zu senken, indem Du die benötigten Daten in möglichst wenigen Abfragen holst und Filterung und Auswahl auf Datenbankebene vornimmst statt im Anwendungs- oder ORM-Code, besonders bei häufig abgerufenen Daten.

Wiederverwendung abgerufener Daten: Rufe Daten nur einmal pro Anfrage oder Vorgang ab und verwende sie lokal weiter, statt Datenbankabfragen zu wiederholen.

Datenminimierung in Abfragen: Grenze Datenbankabfragen so ein, dass nur die tatsächlich benötigten Felder und Datensätze zurückgegeben werden.

Steuerung des Datenlebenszyklus: Wende Steuerungsmechanismen für Datenlebenszyklus und Governance an, etwa Time-to-Live, die Verwendung nicht sensibler Kennungen wie UUIDs, Anonymisierung und die Minimierung gespeicherter Daten im Sinne der Zweckbindung.

Meine Einordnung

Die ersten drei Kriterien oben sind solides Handwerk und beschreiben denselben Grundfehler aus drei Richtungen: zu viele Abfragen, zu oft dieselben, zu viel darin. Der Klassiker ist die Liste, bei der zuerst alle Einträge geholt werden und danach für jeden einzelnen noch eine Zusatzabfrage folgt. Aus einer Abfrage werden so schnell fünfzig. Jede davon kostet Verbindungsaufbau, Rechenzeit und Speicher auf dem Server, und keine davon ist auf der fertigen Seite sichtbar.

Bei mir ist die Lage übersichtlich, und das ist kein Zufall. Diese Website hat für ihre Inhalte überhaupt keine Datenbank. Hugo erzeugt die Seiten vorab aus Textdateien, die Suche arbeitet mit einem fertig gebauten Index, der ebenfalls als Datei ausgeliefert wird. Eine Datenbank läuft bei mir nur an einer einzigen Stelle: für die Statistik mit Matomo. Damit reduziert sich die ganze Frage nach effizienten Abfragen auf genau einen Bereich.

Genau hier verbindet sich diese Guideline mit der Wahl der Architektur. Ein datenbankgetriebenes System ist immer dann sinnvoll, wenn sich Inhalte laufend ändern oder für jeden Besucher unterschiedlich aussehen, also bei einem Shop, einem Portal, einem Buchungssystem. Bei einer Website, deren Inhalte wochenlang unverändert bleiben, ist es überdimensioniert. Du betreibst dann eine Maschine, die für jeden Aufruf neu berechnet, was sich seit dem letzten Mal nicht bewegt hat.

Wo ich weiter gehe

Das vierte Kriterium ist das, dem ich am meisten Gewicht gebe, und es steht auffälligerweise am Ende. Es geht dabei nicht mehr um schnellere Abfragen, sondern um weniger Daten. Aufbewahrungsfristen, Anonymisierung, Zweckbindung. Das ist keine Datenbankoptimierung mehr, das ist Datenhygiene.

Und das ist der Punkt, an dem ich die Reihenfolge der Guideline umdrehen würde. Bevor ich eine Abfrage optimiere, frage ich, ob die Daten dahinter überhaupt vorhanden sein müssen. Bei meiner Statistik heißt das ganz konkret: IP-Adressen gekürzt, Rohdaten nach einer festen Frist gelöscht, nur aggregierte Werte langfristig behalten. Was nicht gespeichert ist, muss nicht abgefragt, nicht gesichert, nicht mitgeschleppt und nicht geschützt werden. Datensparsamkeit ist hier gleichzeitig Klimaschutz und Datenschutz, ohne dass sich beides widerspricht.

Achtung

Eine perfekt optimierte Abfrage auf Daten, die Du gar nicht brauchst, ist optimierte Verschwendung. Bevor Du an der Geschwindigkeit einer Abfrage arbeitest, prüfe, ob der Datensatz dahinter überhaupt existieren muss. Aufbewahrungsfristen sind die wirksamste Datenbankoptimierung, die es gibt.

Dein erster Schritt heute

Der erste Schritt ist, überhaupt sichtbar zu machen, was im Hintergrund passiert. Solange Du die Zahl nicht kennst, diskutierst Du über Gefühle.

Tipp

Fast jedes Redaktionssystem bietet ein Werkzeug, das die Datenbankabfragen eines Seitenaufrufs anzeigt, bei WordPress etwa den Query Monitor. Installiere es auf einer Testumgebung und ruf Deine Startseite auf. Sieh Dir zwei Zahlen an: die Anzahl der Abfragen und die dafür benötigte Zeit. Alles jenseits von ein paar Dutzend Abfragen für eine gewöhnliche Inhaltsseite ist ein Hinweis auf Erweiterungen, die im Hintergrund mitfragen. Deaktiviere versuchsweise einzelne davon und beobachte, wie sich die Zahl verändert.

Und der zweite Handgriff, unabhängig vom System: Setz für Deine Statistik eine Aufbewahrungsfrist. In Matomo findest Du das in den Einstellungen unter Datenschutz, und ein Jahr Rohdaten reicht für die allermeisten Auswertungen völlig aus. Das entlastet Deine Datenbank dauerhaft, ohne dass Du eine einzige Abfrage anfassen musst.

Die sparsamste Datenbankabfrage ist die, für die es gar keine Datenbank braucht.

Quelle: W3C-Fassung von Guideline 3.16