(Ein Beitrag für SQL-Anfänger und tägliche Nutzer)
Wenn du SQL nutzt, kennst du solche Abfragen:
SELECT customer_id, SUM(amount)
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY customer_id;Du schreibst sowas jeden Tag.
Für Reports. Dashboards. APIs. Hintergrundjobs.
Und jedes Mal denkst du:
„Warum dauert das eigentlich immer so lange?“
Die kurze Antwort:
Weil die Datenbank jedes Mal wieder von vorne rechnet.
Das eigentliche Problem
Stell dir vor, du fragst deine Datenbank:
„Wie viel Umsatz hat jeder Kunde dieses Jahr gemacht?“
Am nächsten Tag:
„Wie viel Umsatz hat jeder Kunde diesen Monat gemacht?“
Später:
„Wie viel Umsatz hat Kunde 42 heute gemacht?“
Für dich ist das alles dieselbe Art von Frage.
Für die Datenbank sind es komplett neue Berechnungen.
Sie:
- liest wieder Millionen Zeilen
- sortiert, gruppiert, summiert
- wirft das Ergebnis weg
- und fängt beim nächsten Mal wieder von vorne an
So arbeiten die meisten SQL-Datenbanken heute.
„Aber Datenbanken sind doch schlau?“
Ja – aber vor allem bei:
- Suchen
- Filtern
- Joins
Bei Summen, Zählungen und Gruppierungen gilt oft:
„Rechne alles neu.“
Und genau das ist das Problem.
Was Menschen intuitiv tun würden
Ein Mensch würde sagen:
„Moment – das habe ich doch gestern schon berechnet.
Ich merke mir das Ergebnis und passe es an, wenn neue Daten dazukommen.“
Genau das nennt man Aggregate Caching.
Oder einfacher:
Zwischenergebnisse merken, statt immer neu rechnen.
Warum machen Datenbanken das nicht einfach?
Option 1: „Mach es selbst“
Viele Systeme sagen:
- Lege spezielle Tabellen an
- Pflege sie manuell
- baue Jobs zum Aktualisieren
Problem:
👉 Normale Entwickler wollen das nicht.
Option 2: „Wir merken uns das Ergebnis“
Manche Datenbanken merken sich:
- exakt dieselbe Abfrage
- exakt dieselben Parameter
Problem:
- kleine Änderung → Cache nutzlos
- neue Daten → alles neu
Das fehlende Feature
Was fast keine Open-Source-Datenbank heute kann:
„Ich sehe, dass hier ständig ähnliche Summen berechnet werden.
Ich kümmere mich selbst darum.“
Ohne:
- neue Befehle
- neue Tabellen
- neue Konzepte
Wie sich das ideal anfühlen müsste
Du schreibst normales SQL.
Am Anfang ist es langsam.
Nach ein paar Abfragen plötzlich schnell.
Du hast:
- nichts konfiguriert
- nichts angelegt
- nichts gelernt
Die Datenbank hat einfach gelernt:
„Diese Berechnung lohnt sich zu merken.“
Warum das schwer ist
Weil die Datenbank selbst entscheiden muss:
- was sich lohnt
- wie lange man es behält
- was bei neuen Daten passiert
- was bei wenig Speicher passiert
Das sind harte Probleme.
Aber sie sollten keine Entwicklerprobleme sein.
Fazit
Ein normaler SQL-Nutzer sollte nicht wissen müssen, was:
- Aggregate
- Caches
- Views
- Optimizer
sind.
Er sollte nur merken:
„Meine Abfragen werden mit der Zeit schneller – ganz von allein.“
Dass es dieses Verhalten in Open Source-Datenbanken wie MySQL und PostgreSQL 30 Jahre nach Erforschung dieser Techniken noch nicht gibt, ist eigentlich traurig.
Deshalb schaut euch MemCP an:
English 
German
Comments are closed