Skip to content
NeuralSkills
Fehlerbehebung

Datenbank-Query-Debugger

Langsame Queries, N+1-Probleme, Connection-Pool-Engpaesse und Datenbank-Deadlocks systematisch analysieren und beheben.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Datenbankfehler verbergen sich hinter Abstraktionsschichten. Das ORM generiert eine Query, die gut aussieht, aber 30 Sekunden braucht. Ein Seitenaufruf loest 200 separate Queries aus statt einer (das N+1-Problem). Connection-Pools erschoepfen sich unter Last. Deadlocks erscheinen zufaellig, wenn zwei Transaktionen um dieselben Zeilen kaempfen. Der Anwendungscode sieht korrekt aus — das Problem liegt im generierten SQL, fehlenden Indizes oder Transaktions-Isolationsleveln.

Der Prompt

Du bist ein Datenbank-Debugging-Spezialist. Diagnostiziere dieses Performance- oder Korrektheitsproblem:

DATENBANK: [PostgreSQL/MySQL/MongoDB/SQLite + Version]
ORM/TREIBER: [z.B. Prisma, Sequelize, TypeORM, Drizzle, Raw SQL]
SYMPTOM: [z.B. "Seite laedt 8 Sekunden", "doppelte Datensaetze", "sporadische Connection-Timeouts"]

QUERY ODER ORM-CODE:
[Query, ORM-Aufruf oder generiertes SQL einfuegen]

EXPLAIN-PLAN (falls verfuegbar):
[EXPLAIN ANALYZE-Ausgabe einfuegen]

Fuehre eine Datenbank-Diagnose durch:
1. **Query-Analyse**: Die Query in einfacher Sprache umformulieren. Was fragt sie die Datenbank tatsaechlich? Ist das beabsichtigt?
2. **N+1-Erkennung**: Wird diese Query in einer Schleife ausgefuehrt? Gesamtzahl der Queries pro Seitenaufruf zaehlen. Welche koennen gebatcht oder gejoined werden?
3. **Index-Diagnose**: Basierend auf WHERE, JOIN und ORDER BY — welche Indizes sollten existieren? Existieren sie?
4. **Ausfuehrungsplan lesen**: EXPLAIN-Ausgabe interpretieren — Sequential Scans, fehlende Index-Nutzung, hohe Zeilenschaetzungen identifizieren.
5. **Connection-Pool-Health**: Pool-Groesse, Idle-Timeout und Max-Connections gegen gleichzeitiges Request-Volumen pruefen.
6. **Die optimierte Query**: Umgeschriebene Query liefern, die das Performance-Problem loest.

Beispiel-Ausgabe

Query-Analyse: ORM generiert SELECT * (47 Spalten) obwohl nur 3 benoetigt werden — 15x mehr Datentransfer als noetig
N+1 erkannt: UserList-Komponente loest 1 Query fuer User + 1 Query pro User fuer Avatar aus — 201 Queries fuer 200 User
Fehlender Index: WHERE email = $1 loest Sequential Scan auf 2M-Zeilen-Tabelle aus — Index reduziert Query von 2100ms auf 3ms
Connection-Pool: Max ist 5 (Standard), App bearbeitet 50 gleichzeitige Requests — Requests stehen Schlange
Fix: .select('id', 'name', 'email') + .include('avatar') fuer Eager Loading. Index hinzufuegen. Pool-Max auf 20 setzen.

Wann verwenden

Diesen Skill einsetzen bei langsamen Seitenaufrufen trotz schnellem Anwendungscode, hoher Datenbank-CPU oder I/O, doppelten oder fehlenden Datensaetzen, oder Connection-Timeout-Fehlern unter Last.

Profi-Tipps

  • Immer EXPLAIN ANALYZE, nicht nur EXPLAIN — EXPLAIN zeigt den Plan, EXPLAIN ANALYZE fuehrt die Query tatsaechlich aus und zeigt echte Ausfuehrungszeiten.
  • Alle Queries in Entwicklung loggen — SQL-Logging im ORM aktivieren, um zu sehen, welches SQL generiert wird und wie viele Queries jeder Seitenaufruf ausloest.
  • Die 10-Query-Regel — wenn ein Seitenaufruf mehr als 10 Datenbank-Queries ausfuehrt, liegt fast sicher ein N+1-Problem vor.
  • Indizes sind nicht kostenlos — jeder Index beschleunigt Reads, verlangsamt aber Writes. Bei schreibintensiven Tabellen beides profilen.