Claude für SQL-Query-Generierung und Review

1. Warum SQL-Query-Generierung mit Claude ein eigenes Vorgehen braucht

Claude kann syntaktisch korrektes SQL fast immer erzeugen, das ist nicht das eigentliche Problem. Die Herausforderung bei der SQL-Query-Generierung liegt darin, dass ein Sprachmodell das tatsächliche Datenbankschema, die Kardinalitäten zwischen Tabellen und die Indizierung nicht kennt, wenn man sie ihm nicht mitteilt. Eine Query kann syntaktisch perfekt sein und trotzdem auf einer Million Zeilen einen Full-Table-Scan auslösen, weil das Modell nicht wusste, dass eine Spalte keinen Index trägt. Genau hier entscheidet sich, ob Claude als Zeitersparnis oder als Risikoquelle wirkt.

Der zweite Aspekt betrifft das SQL Review: Bestehende Abfragen, die über Jahre gewachsen sind, enthalten oft implizite Annahmen, die niemand mehr dokumentiert hat. Claude liest solche Queries nicht mit Betriebsblindheit, sondern stellt Fragen, die ein Mensch nach jahrelanger Gewöhnung nicht mehr stellt: Warum dieser LEFT JOIN, wenn nirgends NULL-Werte erwartet werden? Warum kein Index auf der Filterspalte? Dieser Artikel zeigt, wie man Claude sowohl für die Generierung neuer Queries als auch für das Review bestehender SQL-Abfragen produktiv einsetzt, ohne blind zu vertrauen.

2. Vom Schema zur Query: den richtigen Kontext liefern

Die Qualität einer generierten Query hängt fast vollständig von der Qualität des mitgelieferten Schemas ab. Statt Claude nur den Tabellennamen zu nennen, sollte man CREATE TABLE-Statements mit allen Spalten, Datentypen, Primärschlüsseln, Fremdschlüsseln und vorhandenen Indizes einfügen. Fehlt diese Information, rät Claude bei Spaltennamen und erzeugt Queries, die zwar plausibel aussehen, aber auf falschen Annahmen beruhen. Bei SQL-Query-Generierung in Claude Code lohnt es sich, das Schema einmal in eine Datei zu exportieren und im Prompt zu referenzieren, statt es bei jeder Anfrage neu abzutippen.

Ein zweiter wichtiger Kontext-Baustein ist die ungefähre Datenmenge pro Tabelle. Eine Query, die für 500 Zeilen sinnvoll ist, kann bei 50 Millionen Zeilen völlig andere Ausführungspläne brauchen. Claude reagiert auf diese Information deutlich anders: Bei großen Tabellen schlägt das Modell eher Indizes, LIMIT-Klauseln oder Pagination vor, bei kleinen Referenztabellen verzichtet es auf unnötige Optimierungen. Wer regelmäßig mit demselben Schema arbeitet, sollte diesen Kontext in einer projektbezogenen CLAUDE.md hinterlegen, damit er nicht jedes Mal neu formuliert werden muss.

-- Schema context for Claude: paste full DDL, not just table names
CREATE TABLE orders (
  order_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  customer_id BIGINT UNSIGNED NOT NULL,
  status ENUM('pending', 'processing', 'shipped', 'cancelled') NOT NULL,
  total_amount DECIMAL(10,2) NOT NULL,
  created_at DATETIME NOT NULL,
  INDEX idx_customer (customer_id),
  INDEX idx_status_created (status, created_at)
) ENGINE=InnoDB;
-- Approximate row count: 4.2 million rows, growing ~30k/day

CREATE TABLE order_items (
  item_id BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  order_id BIGINT UNSIGNED NOT NULL,
  sku VARCHAR(64) NOT NULL,
  quantity INT UNSIGNED NOT NULL,
  unit_price DECIMAL(10,2) NOT NULL,
  FOREIGN KEY (order_id) REFERENCES orders(order_id),
  INDEX idx_sku (sku)
) ENGINE=InnoDB;
-- Approximate row count: 11 million rows

-- Prompt: "Generate a query returning top 20 customers by revenue
-- in the last 90 days, using the schema and row counts above."

3. Komplexe JOINs und Aggregationen generieren lassen

Sobald mehr als zwei Tabellen beteiligt sind, wird das manuelle Schreiben von JOINs fehleranfällig. Kardinalitätsfehler, doppelte Zeilen durch einen fehlenden GROUP BY oder falsch platzierte WHERE-Bedingungen in Verbindung mit LEFT JOINs sind die häufigsten Fehlerquellen. Bei der SQL-Query-Generierung mit Claude lohnt es sich, das gewünschte Ergebnis in einem Satz zu beschreiben, statt die JOIN-Logik selbst vorzugeben. Claude wählt dann INNER JOIN, LEFT JOIN oder Subqueries je nach beschriebener Anforderung und erklärt die Wahl, wenn man danach fragt.

Fensterfunktionen wie ROW_NUMBER(), RANK() oder LAG() sind ein weiterer Bereich, in dem Claude nachweislich hilft, weil die Syntax zwar dokumentiert, aber selten intuitiv ist. Für Aufgaben wie "die letzten drei Bestellungen pro Kunde" oder "prozentuale Veränderung zum Vormonat" liefert Claude fertige Fensterfunktions-Konstrukte, die man sonst erst nachschlagen müsste. Wichtig bleibt: jede generierte Aggregation sollte gegen ein bekanntes Testergebnis geprüft werden, bevor sie in ein Reporting einfließt.

-- Generated by Claude from schema above + natural language request:
-- "Top 20 customers by revenue in the last 90 days, with order count"
SELECT
  c.customer_id,
  c.email,
  COUNT(DISTINCT o.order_id) AS order_count,
  SUM(oi.quantity * oi.unit_price) AS total_revenue,
  ROUND(SUM(oi.quantity * oi.unit_price) / COUNT(DISTINCT o.order_id), 2) AS avg_order_value
FROM customers c
INNER JOIN orders o ON o.customer_id = c.customer_id
INNER JOIN order_items oi ON oi.order_id = o.order_id
WHERE o.status != 'cancelled'
  AND o.created_at >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY c.customer_id, c.email
ORDER BY total_revenue DESC
LIMIT 20;

-- Follow-up prompt: "Add month-over-month revenue change per customer
-- using a window function, without a second query"
SELECT
  customer_id,
  revenue_month,
  monthly_revenue,
  LAG(monthly_revenue) OVER (PARTITION BY customer_id ORDER BY revenue_month) AS prev_month,
  ROUND(
    (monthly_revenue - LAG(monthly_revenue) OVER (PARTITION BY customer_id ORDER BY revenue_month))
    / NULLIF(LAG(monthly_revenue) OVER (PARTITION BY customer_id ORDER BY revenue_month), 0) * 100, 1
  ) AS pct_change
FROM customer_monthly_revenue;

4. Query-Review: Claude als zweiter Blick vor dem Deploy

Neben der Generierung ist das SQL Review bestehender Abfragen der zweite große Anwendungsfall. Statt eine fertige Query nur auf syntaktische Korrektheit zu prüfen, lohnt sich ein gezielter Review-Prompt: Man fügt die Query zusammen mit dem Schema ein und bittet Claude explizit um eine Einschätzung zu Performance, Lesbarkeit und Korrektheit der Ergebnismenge. Claude erkennt dabei zuverlässig Muster wie implizite Type-Casts in WHERE-Klauseln, die einen Index unbrauchbar machen, oder SELECT * in Produktionscode, wo nur drei Spalten benötigt werden.

Besonders wertvoll ist das Review bei Legacy-Queries, die von mehreren Entwicklern über Jahre erweitert wurden. Claude findet dort häufig redundante Subqueries, die durch einen einzigen JOIN ersetzbar wären, oder Bedingungen, die sich gegenseitig ausschließen und deshalb nie greifen. Der Review-Prozess funktioniert am besten iterativ: erst eine allgemeine Einschätzung anfordern, dann gezielt zu einzelnen Auffälligkeiten nachfragen, statt alles in einem Schritt korrigieren zu lassen.

-- Query submitted for review, with schema context attached
SELECT * FROM orders o
WHERE o.customer_id IN (
  SELECT customer_id FROM customers WHERE country = 'DE'
)
AND CAST(o.status AS CHAR) = 'shipped'
ORDER BY o.created_at DESC;

-- Claude's review findings, applied:
-- 1. SELECT * fetches unused columns — list only what the caller needs
-- 2. CAST on an ENUM column disables the idx_status_created index
-- 3. Subquery can become a JOIN, often faster with the optimizer used here
SELECT o.order_id, o.total_amount, o.created_at
FROM orders o
INNER JOIN customers c ON c.customer_id = o.customer_id
WHERE c.country = 'DE'
  AND o.status = 'shipped'
ORDER BY o.created_at DESC;

5. Performance-Fallstricke: EXPLAIN gemeinsam mit Claude lesen

Ein EXPLAIN- oder EXPLAIN ANALYZE-Output ist für Entwickler ohne DBA-Hintergrund oft schwer zu deuten. Claude übersetzt die Ausgabe in verständliche Aussagen: Welcher Join-Typ wurde gewählt, wie viele Zeilen wurden tatsächlich untersucht, wo entstand ein temporäres Filesort. Der praktische Workflow: Query ausführen, EXPLAIN-Output kopieren, zusammen mit der Query an Claude geben und gezielt nach dem teuersten Schritt im Ausführungsplan fragen.

Besonders nützlich ist dieser Ansatz, wenn eine Query in der Entwicklungsumgebung mit wenig Testdaten schnell ist, in Produktion mit Millionen Zeilen aber plötzlich Sekunden statt Millisekunden braucht. Claude kann anhand des EXPLAIN-Plans konkrete Gegenmaßnahmen vorschlagen, etwa einen zusammengesetzten Index, eine Umformulierung der WHERE-Klausel oder das Aufteilen einer Query in zwei einfachere Schritte. Wichtig ist, dass man den vorgeschlagenen Index tatsächlich testet, bevor man ihn in die Produktionsmigration übernimmt, denn zusätzliche Indizes kosten auch bei jedem INSERT und UPDATE Zeit.

# Practical EXPLAIN workflow with Claude Code
mysql -e "EXPLAIN ANALYZE SELECT * FROM orders
  WHERE status = 'pending' AND created_at > '2026-01-01'\G" > explain.txt

# Prompt: "Here is the query and the EXPLAIN ANALYZE output.
# Which step is the most expensive, and what index would help?"
cat explain.txt
# -> rows=4200000 examined, type=ALL, Extra: Using where; Using filesort
# Claude's suggestion: composite index on (status, created_at)
# reduces the scan to an index range scan (type=range)

# Verify before applying to production
mysql -e "CREATE INDEX idx_status_created ON orders(status, created_at);"
mysql -e "EXPLAIN ANALYZE SELECT * FROM orders
  WHERE status = 'pending' AND created_at > '2026-01-01'\G"
# -> rows=1800, type=range, Extra: Using index condition

6. Sichere Query-Generierung: Injection und Parametrisierung

Wenn Claude nicht nur reines SQL, sondern die Anbindung an eine Anwendungssprache generiert, entsteht das Risiko von SQL-Injection, falls Nutzereingaben direkt in Query-Strings verkettet werden. Claude neigt in kurzen Beispiel-Snippets manchmal zu einfacher String-Interpolation, wenn der Prompt keine Sicherheitsanforderung nennt. Der zuverlässige Gegenmaßnahme: Im Prompt explizit "Prepared Statements mit gebundenen Parametern" fordern, dann generiert Claude durchgängig parametrisierten Code statt String-Konkatenation.

Bei der SQL-Query-Generierung für PHP-Projekte ist PDO mit gebundenen Parametern der Standard, den man in der Projekt-CLAUDE.md verankern sollte, damit jede spätere Anfrage diese Vorgabe automatisch respektiert. Ein zusätzlicher Sicherheitscheck im Review-Schritt: Claude bitten, jede generierte Datenbankanbindung explizit auf Injection-Anfälligkeit zu prüfen, bevor der Code gemerged wird. Das ersetzt keine automatisierten Security-Scanner, ergänzt sie aber sinnvoll als schnelle erste Kontrolle.

<?php
declare(strict_types=1);

// WRONG: string concatenation is vulnerable to SQL injection
// $sql = "SELECT * FROM orders WHERE customer_id = " . $customerId;

// RIGHT: prepared statement with bound parameters, as requested from Claude
final class OrderRepository
{
    public function __construct(private readonly \PDO $connection)
    {
    }

    /**
     * Fetches recent orders for a given customer using a bound parameter.
     *
     * @param int $customerId Customer identifier from validated request data.
     * @return array<int, array<string, mixed>> Rows matching the criteria.
     */
    public function findRecentByCustomer(int $customerId): array
    {
        $statement = $this->connection->prepare(
            'SELECT order_id, status, total_amount, created_at
             FROM orders
             WHERE customer_id = :customerId
             ORDER BY created_at DESC
             LIMIT 20'
        );
        $statement->execute(['customerId' => $customerId]);

        return $statement->fetchAll(\PDO::FETCH_ASSOC);
    }
}

7. Claude für Magento- und Hyvä-Datenbankarbeit einsetzen

In Magento-Projekten kommt eine zusätzliche Komplexitätsebene hinzu: EAV-Tabellen, Flat-Indizes und die Magento-eigene Select-Query-Builder-API statt reinem SQL. Claude generiert brauchbaren Code für beides, sofern man im Prompt klarstellt, ob rohes SQL für ein Reporting-Skript oder ein ResourceModel mit dem Magento-Query-Builder benötigt wird. Bei EAV-Abfragen ist die Angabe des konkreten Attribut-Codes und der Entity-Type-ID entscheidend, weil Claude sonst generische, aber falsche Attribut-Joins erzeugt.

Für Performance-Analysen an Magento-Datenbanken hilft derselbe EXPLAIN-Workflow wie in Abschnitt fünf beschrieben, mit dem Unterschied, dass viele Magento-Tabellen wie catalog_product_entity_int oder sales_order_grid spezielle Indizierungsmuster haben, die man Claude im Kontext mitgeben sollte. Ein häufiger Anwendungsfall in der Hyvä-Entwicklung ist das Debuggen langsamer Kategorie- oder Suchseiten, bei denen die generierte Query erst gegen die tatsächliche EXPLAIN-Ausgabe der Magento-Instanz geprüft werden muss, bevor sie in ein Custom-Modul übernommen wird.

8. Iterativer Workflow von der Rohanfrage zur fertigen Query

Der produktivste Ansatz bei der SQL-Query-Generierung ist selten "einmal fragen, fertig kopieren". Stattdessen entsteht die beste Query iterativ: erste Version generieren lassen, gegen echte Testdaten ausführen, Abweichungen vom erwarteten Ergebnis benennen, Claude um eine korrigierte Version bitten. Dieser Zyklus dauert bei komplexen Reports selten mehr als drei bis vier Runden und ist trotzdem deutlich schneller als das manuelle Schreiben und Debuggen derselben Query von Grund auf.

Ein bewährtes Muster: Nach der finalen Query explizit um eine kurze Erklärung jeder Klausel bitten. Das erzeugt nebenbei eine Dokumentation, die spätere Wartungsarbeiten erleichtert, und zwingt einen selbst dazu, die generierte Logik tatsächlich zu verstehen, statt sie unreflektiert zu übernehmen. Wer diesen Schritt regelmäßig überspringt, läuft Gefahr, Queries in Produktion zu haben, die niemand im Team vollständig nachvollziehen kann.

9. SQL-Query-Generierung im direkten Vergleich

Je nach Aufgabe unterscheidet sich, wie viel Kontext und wie viele Iterationsschritte für ein zuverlässiges Ergebnis nötig sind. Die folgende Übersicht ordnet typische Aufgaben nach Aufwand und Risiko bei der Nutzung von Claude für SQL-Query-Generierung und Review ein.

Der klare Trend: Je mehr strukturierter Kontext im Prompt steckt, desto seltener muss nachkorrigiert werden. Zeit, die in den ersten Prompt investiert wird, spart in der Regel mehrere Korrekturschleifen später ein, besonders bei komplexen Reporting-Queries mit vielen JOINs und Aggregationen.

10. Zusammenfassung

Claude für SQL-Query-Generierung und Review funktioniert dann zuverlässig, wenn das Schema, die ungefähre Zeilenzahl und die Sicherheitsanforderungen explizit im Prompt stehen. Komplexe JOINs, Fensterfunktionen und Aggregationen lassen sich deutlich schneller generieren als von Hand schreiben, solange das Ergebnis gegen echte Testdaten geprüft wird. Beim Review deckt Claude Muster auf, die im Alltag leicht übersehen werden: implizite Type-Casts, die Indizes unbrauchbar machen, redundante Subqueries und fehlende Parametrisierung.

EXPLAIN-Analysen werden mit Claude als Übersetzer deutlich zugänglicher, auch für Entwickler ohne tiefes DBA-Wissen. In Magento- und Hyvä-Projekten kommt die zusätzliche Komplexität von EAV-Strukturen hinzu, die mit konkretem Attribut- und Entity-Kontext beherrschbar bleibt. Der iterative Workflow, generieren, testen, korrigieren, bleibt der zuverlässigste Weg zu produktionsreifen Queries.

11. FAQ: Claude für SQL-Query-Generierung und Review