SQL-Abfrage Generierung
Sag AI was du brauchst, sie schreibt die SQL
SQL schreiben – die Fallstricke
Drei Tabellen JOINen, am Ende zeigt Ergebnis zehnfach mehr Zeilen – welcher JOIN war falsch? Halbe Stunde debuggen bis klar: Many-to-Many Beziehung nicht beachtet.
Subquery drei Ebenen tief verschachtelt, am Ende nur du nicht mehr lesen was es macht. Kollege fragt „was macht diese SQL", du antwurst „gib mir zwei Minuten um zu denken".
Noch schlimmer: Performance-Problem – Query läuft 30 Sekunden, EXPLAIN anschauen hilft nicht weiter. Index hinzufügen macht's nur langsamer? Total confused.
Du fragst Umgangssprache „zeig mir Ausgaben pro Kunde in den letzten 30 Tagen, descending nach Summe" – OpenClaw gibt dir saubere SQL.
Nicht bloß übersetzen: bedenkt Table-Beziehungen, Datenmengen, bestehende Indizes – die SQL ist korrekt UND performant.
Langsame Query? SQL + EXPLAIN-Ausgabe rein, es sagt wo Bottleneck, welcher Index fehlt, wie man schneller schreibt.Praktisch ein DBA der immer antwortet.
3 SQL-Prompts – 90% der täglichen Aufgaben
Von Anfänger-Abfragen bis Performance-Tuning.
Datenbank hat diese Tabellen:
- users (id, name, email, channel, created_at, status)
- user_profiles (user_id, age, gender, city)
SQL schreiben:
1. Täglich neue User letzte 30 Tage
2. Nach Registrations-Channel gruppieren
3. Jeden Channel: Next-Day Retention Rate auch
4. Nach Datum descending sortieren
Datenbank: MySQL 8.0, users-Tabelle ca. 5 Mio. Zeilen.
Indexe-Empfehlungen auch geben.Diese SQL läuft 30 Sekunden, bitte fix:
[SQL hier paste]
EXPLAIN-Ausgabe:
[EXPLAIN hier paste]
Analysiere:
1. Wo ist der Bottleneck (Full-Scan? Temp-Table? Filesort?)
2. Welche Indizes bauen (CREATE INDEX statements)
3. SQL-Umschreiben schneller (alternative Syntax)
4. Geschätzte Zeit nach Optimierung
Datenbank: PostgreSQL 15, Tabellen ca. 20 Mio. Zeilen.Drei Tabellen:
- users (id, name, registered_at)
- orders (id, user_id, product_id, amount, created_at, status)
- products (id, name, category, brand)
Query schreiben:
1. Summe Ausgaben pro Nutzer (nur completed Orders)
2. Top-Kategorie pro Nutzer (die mit meisten Käufen)
3. Erster und letzter Kauf Datum pro Nutzer
4. Nur Nutzer letzte Jahr mit Käufen
5. Absteigend nach Ausgaben, Top 100
Datenbank: MySQL 8.0. Bitte CTE nutzen um lesbar zu machen.Datenbank-Verbindungs-Setup
Optional: OpenClaw direkt Database-Zugriff (nicht nötig für SQL-Generierung).
# Datenbank-Zugriff (optional, mit Config kann AI direkt abfragen und Ergebnisse verifizieren)
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # STARK EMPFOHLEN: nur Read-Account!
password_env: DB_PASSWORD # Passwort aus Environment-Variable, nicht plain-text
# Sicherheits-Einstellung
read_only: true # Nur SELECT erlaubt, keine Datenänderungen
max_rows: 10000 # Max Zeilen pro Query
timeout: 30 # Query-Timeout (Sek)
# Datenbank nicht konfiguriert? Kein Problem.
# AI generiert SQL basierend auf deine Tabel-Beschreibung.
# Kann nur nicht direkt Ergebnisse verifizieren.SQL schreiben: OpenClaw vs. ChatGPT
Beide generieren SQL, aber Details unterscheiden sich.
- Kann deine Database-Schema lesen, generierte SQL passt perfekt
- Kann direkt DB-Zugriff mit verifizieren (Read-Account Setup)
- Kontext behalten: bisherige Querys, Table-Beziehungen, Fragen-Details
- Lokal ausführen, Tabel-Struktur und Business-Logik privat
- Nur auf deine Beschreibung vom Schema gestützt, viel Guessgork
- Kann SQL nicht direkt laufen, Syntax-Fehler erst später sichtbar
- Context-Fenster begrenzt, komplexe Business-Logik vergisst vergessen
- SQL-Syntax passt, aber Logik manchmal falsch – schwierig zu debuggen