SQL-Formatierer & Beautifier — 11 Dialekte, Minify, Hervorhebung
Formatiere unordentliches SQL zu lesbaren, einheitlich eingerückten Abfragen für PostgreSQL, MySQL, T-SQL, BigQuery und mehr. Läuft im Browser.
Läuft komplett in deinem Browser. Dein SQL wird nie an einen Server gesendet, Schemanamen und Daten in Abfragen bleiben also privat. Alle kostenlosen Tools ansehen.
Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.
Dieser kostenlose SQL-Formatierer macht aus einer Abfrage, die du aus einem Log, einem ORM oder einer einzeiligen Migration kopiert hast, lesbares SQL: eine Klausel pro Zeile, einheitliche Einrückung und Keywords in der Schreibweise deiner Wahl. Wähle deinen Datenbankdialekt, damit Syntax wie Casts mit :: und $$-Funktionsrümpfe in PostgreSQL, Backticks in MySQL, [Klammern] und @Variablen in T-SQL oder QUALIFY-Klauseln in BigQuery und Snowflake verstanden statt zerstückelt wird.
Das Formatieren ändert nur Leerraum und die Schreibweise von Keywords, Datentypen und Funktionsnamen. String-Literale, Bezeichner in Anführungszeichen und Kommentare bleiben genau so, wie sie geschrieben sind. Der Formatierer muss dein SQL parsen, um es zu layouten, daher kann templatisiertes SQL (dbt- oder Jinja-Blöcke mit {{ }}) und manche herstellerspezifische Anweisung scheitern; dann sagt er dir, an welcher Zeile und Spalte er gestoppt hat. Minify macht das Gegenteil: eine Zeile, Kommentare entfernt, Optimizer-Hints wie /*+ INDEX(...) */ bleiben erhalten.
So funktioniert’s
- Füge eine oder mehrere SQL-Anweisungen in das Feld ein. Eine Beispielabfrage ist geladen, damit du zuerst das Ergebnis siehst.
- Wähle den Dialekt deiner Datenbank. Das ist vor allem für Quoting, Parameter und herstellerspezifische Syntax wichtig.
- Stelle Keyword-Schreibweise, Einrückung und die Anzahl der Leerzeilen zwischen Anweisungen ein. Die Ausgabe aktualisiert sich bei jeder Änderung.
- Wechsle zu „Minify“, wenn du die Abfrage in einer einzigen Zeile brauchst, etwa in einer JSON-Konfiguration oder einem Shell-Befehl.
- Kopiere das Ergebnis oder lade es als .sql-Datei herunter.
Häufige Fragen
Ändert das Formatieren, was meine SQL-Abfrage tut?
Nein. Der Formatierer ändert nur Leerraum und die Groß-/Kleinschreibung von Keywords, Datentypen und Funktionen, die SQL-Datenbanken ohne Unterscheidung der Schreibweise behandeln. String-Werte, Bezeichner in Anführungszeichen ("Column", `col`, [col]) und Kommentare werden unverändert übernommen, die Abfrage liefert also dieselben Ergebnisse. Tabellen- und Spaltennamen werden nicht umgeschrieben, mit einer Ausnahme: Ein Name ohne Anführungszeichen, der im gewählten Dialekt auch ein Keyword ist (etwa ein Alias namens month), folgt der Keyword-Schreibweise. Namen ohne Anführungszeichen sind in den meisten Datenbanken unabhängig von der Schreibweise, das spielt also selten eine Rolle, aber Tabellennamen in MySQL können unter Linux schreibweisenabhängig sein; wähle „Beibehalten“, um deinen Text genau so zu lassen, wie er geschrieben ist.
Welchen SQL-Dialekt soll ich wählen?
Den, den deine Datenbank verwendet. Standard-SQL funktioniert für einfache SELECT-, INSERT- und UPDATE-Anweisungen, kennt aber keine Casts mit :: und $1-Parameter aus PostgreSQL, keine Backtick-Bezeichner und #-Kommentare aus MySQL, keine eckigen Klammern, @Variablen und TOP aus T-SQL, keine PL/SQL-Blöcke von Oracle und keine QUALIFY-Klausel aus BigQuery und Snowflake. Scheitert das Formatieren mit einem Parse-Fehler, ist der richtige Dialekt das Erste, was du ausprobieren solltest.
Warum meldet der Formatierer „Parse error“?
Er ist auf ein Token gestoßen, das er im gewählten Dialekt nicht erwartet hat. Häufige Ursachen sind ein falscher Dialekt, eine nicht geschlossene Klammer oder ein nicht geschlossenes Anführungszeichen, Template-Platzhalter wie {{ ref("orders") }} aus dbt oder prozeduraler Code, den der Parser nicht abdeckt. Die Statuszeile zeigt Zeile und Spalte, und das Feld darunter zeigt auf das Zeichen – das reicht meist, um das Problem zu finden.
Sollten SQL-Keywords großgeschrieben werden?
Das ist eine Konvention, keine Regel. Großgeschriebene Keywords (SELECT, FROM, WHERE) heben die Struktur von Tabellen- und Spaltennamen ab und sind der verbreitetste Stil in Dokumentationen und Style-Guides. Viele Teams, die dbt oder moderne Editoren mit Syntaxhervorhebung nutzen, bevorzugen Kleinschreibung. Entscheide dich für eins und wende es überall an; dieses Tool kann in beide Richtungen umwandeln oder beibehalten, was du geschrieben hast.
Ist es sicher, SQL zu minifizieren?
Für die Abfrage selbst ja: Beim Minifizieren wird Leerraum zusammengefasst und -- sowie /* */-Kommentare werden entfernt, das Innere von Strings wird nie angetastet. Optimizer-Hints (/*+ ... */) und MySQL-Versionskommentare (/*! ... */) bleiben erhalten, weil sie das Verhalten ändern. Der Preis ist die Lesbarkeit – minifiziere also nur für den Transport (eine JSON-Konfiguration, eine Umgebungsvariable, eine Logzeile) und behalte die formatierte Fassung in deinem Repository.
Wird mein SQL an einen Server gesendet?
Nein. Die Formatierer-Bibliothek wird in deinen Browser geladen und läuft dort. Tabellennamen, Spaltennamen und Daten in deinen WHERE-Klauseln verlassen nie deinen Rechner.
Dialektunterschiede, an denen Formatierer scheitern
• Quoting von Bezeichnern: Standard-SQL und PostgreSQL verwenden "doppelte Anführungszeichen", MySQL und MariaDB `Backticks`, SQL Server [eckige Klammern]. Ein Formatierer mit dem falschen Dialekt kann einen Namen in Anführungszeichen als String oder Operator lesen.
• Parameter: PostgreSQL verwendet $1, $2; MySQL und SQLite verwenden ?; SQL Server verwendet @name; Oracle verwendet :name. Sie bleiben genau so, wie sie geschrieben sind.
• Casts und Operatoren: PostgreSQL hat value::type, die JSON-Operatoren -> und ->> sowie ILIKE. BigQuery und Snowflake haben QUALIFY zum Filtern von Fensterfunktionen. Spark und Hive haben LATERAL VIEW.
• Strings und Rümpfe: Funktionsrümpfe in PostgreSQL stehen oft in $$ ... $$ (Dollar-Quoting), und Escape-Strings verwenden E'...'. Alles darin wird als ein String behandelt und in Ruhe gelassen.
• Kommentare: -- und /* */ funktionieren überall; # leitet nur in MySQL und MariaDB einen Kommentar ein. In T-SQL ist #name eine temporäre Tabelle.
Ein lesbarer SQL-Stil in fünf Regeln
Veröffentlichte SQL-Style-Guides unterscheiden sich in Details wie führenden oder nachgestellten Kommas, die meisten sind sich aber über ein paar Layoutregeln einig, und dieser Formatierer wendet sie standardmäßig an:
• Eine Hauptklausel pro Zeile: SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT.
• Eine ausgewählte Spalte pro Zeile, damit Diffs genau zeigen, welche Spalte sich geändert hat.
• Bedingungen nach AND oder OR in eigenen Zeilen innerhalb von WHERE und ON.
• Unterabfragen und CTE-Rümpfe eine Ebene tiefer eingerückt als ihr Elternelement.
• Eine Leerzeile zwischen Anweisungen in einem Skript, damit sich jede Anweisung als Einheit liest.
Was ein Formatierer nicht kann, ist gute Namen vergeben. Verwende Tabellenaliasse, die etwas bedeuten (orders o ist in Ordnung, t1 nicht), und gib berechneten Spalten einen expliziten AS-Namen.
Ähnliche kostenlose Tools
- JSON Formatter — JSON formatieren, minifizieren und validieren, Parse-Fehler mit Zeile und Spalte. Im Browser, ohne Upload.
- JSON in TypeScript — Füge ein JSON-Beispiel ein und erhalte TypeScript-Interfaces, ein Zod-Schema, ein JSON Schema oder Typen für Go, Python, Java, C#, Kotlin, Swift und Rust.
- YAML-Validator — Prüfe YAML mit exakter Zeile und Spalte jedes Fehlers und finde die Fehler, die Parser stillschweigend akzeptieren: yes/no-Booleans, Tabs, doppelte Schlüssel.
- Regex-Tester — Teste einen regulären Ausdruck an Beispieltext mit Live-Hervorhebung der Treffer, Capture Groups und Vorschau fürs Ersetzen. Kostenlos, im Browser.
- Diff-Checker — Vergleiche zwei Versionen eines Textes, Codes oder einer JSON-Datei und sieh genau, welche Zeilen, Wörter und Zeichen sich geändert haben.