SQL-Formatter

Fügen Sie eine einzeilige SQL-Anweisung ein, die aus einem Protokoll oder einem ORM kopiert wurde, und der Formatter zerlegt sie in eingerückte Klauseln mit konsistenter Schlüsselwortschreibung, Zeilenumbrüchen vor SELECT, FROM, WHERE, GROUP BY und ausgerichteten Spalten in der Projektion. Unterstützt MySQL, PostgreSQL, SQL Server, Oracle, SQLite und BigQuery-Dialekte, jeder hat leicht unterschiedliche Schlüsselwörter und reservierte Wörter.

Wie das Formatieren funktioniert

  1. 1

    Fügen Sie Ihr SQL ein

    Einzeiliger Blob, minimierte Ausgabe von Hibernate, was auch immer. Mehrere Anweisungen, die durch `;` getrennt sind, werden alle formatiert.

  2. 2

    Wählen Sie Dialekt und Stil

    Der Dialekt steuert die Schlüsselwortliste; der Stil steuert die Kommaplatzierung (führend vs. nachfolgend), Einrückbreite und Groß-/Kleinschreibung der Schlüsselwörter.

  3. 3

    Tokens werden geparst, nicht regex-ersetzt

    Ein Tokenizer behandelt Strings, Kommentare, Klammern und Unterabfragen korrekt. String-Literale werden unverändert beibehalten.

  4. 4

    Kopieren Sie die formatierte Ausgabe

    Validiertes SQL, dieselbe Semantik, saubereres Layout.

Vorher und nachher

Vorher:

SELECT u.id,u.name,COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Nachher (führendes Komma, Großbuchstaben für Schlüsselwörter, 2 Leerzeichen Einrückung):

SELECT
    u.id
  , u.name
  , COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
WHERE u.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Stilentscheidungen, die wichtig sind

  • Großbuchstaben vs. Kleinbuchstaben für Schlüsselwörter. GROSSBUCHSTABEN ist traditionell und gut lesbar. Kleinbuchstaben sind in modernen Code-Editoren mit Syntaxhervorhebung sauberer.
  • Führende vs. nachfolgende Kommas. Führende ( , col) erleichtert das Kommentieren einer einzelnen Spalte. Nachfolgende (col,) liest sich natürlicher im Text.
  • Kommaplatzierung in GROUP BY. Oft eine pro Zeile für lange Klauseln, inline für kurze.
  • JOIN-Einrückung. ON in der nächsten Zeile (hängende Einrückung) vs. in derselben Zeile. Lange Bedingungen profitieren von hängenden Einrückungen.
  • Unterabfragen. Die gesamte Unterabfrage einrücken, nicht nur die öffnende Klammer.

Dialekt-spezifische Fallstricke

  • MySQL-Backticks vs. PostgreSQL-Doppelanführungszeichen für Bezeichner.
  • WITH CTEs, MS SQL hat eine ;-Anforderung vor WITH; der Formatter kümmert sich darum.
  • Fensterfunktionen, lange OVER (...)-Klauseln profitieren von umgebrochenem PARTITION BY und ORDER BY.
  • BigQuery hat ARRAY_AGG, STRUCT und Tabellensuffixe (*_yyyymmdd), die der Tokenizer nicht brechen darf.
  • Oracle hat die (+)-Syntax für äußere Joins, der Formatter bewahrt sie, kennzeichnet sie jedoch als veraltet.

Was der Formatter nicht tut

  • Fehler beheben, ein ungültiger JOIN bleibt ungültig.
  • SELECT * erweitern, Spaltenlisten werden nicht aus dem Schema abgeleitet.
  • Abfragen optimieren, nur Layout, keine Ausführungspläne.
  • Unterabfragen als CTEs umschreiben, ein anderes Anliegen.

Häufig gestellte Fragen

Nein, es ist rein kosmetisch. Leerzeichen, Zeilenumbrüche und Kommaplatzierung werden verschoben, aber Schlüsselwörter, Operatoren, Literale und Bezeichner werden genau beibehalten.

Unterstützt, CREATE TABLE, ALTER, CREATE PROCEDURE, Trigger. Der Formatter behandelt Blockkonstrukte (BEGIN ... END) und Zeilenfortsetzungen innerhalb von Prozeduren.

Sollte nicht, wenn doch, liegt es wahrscheinlich an einem Dialekt-Mismatch. Versuchen Sie, den Dialekt zu wechseln. Bitte melden Sie anhaltende Fehler; wir behandeln sie als Bugs.

Flink SQL und Cassandra CQL sehen ähnlich aus, haben jedoch dialekt-spezifische Schlüsselwörter, die gängige Formatter durcheinanderbringen. Verwenden Sie es mit Vorsicht und überprüfen Sie, ob die Ausgabe funktioniert.

Verwandte Tools

Tool in anderen Sprachen verfügbar