SQL-Formatierungstool
Was ist SQL-Formatierung?
Der SQL-Formatter strukturiert SQL-Abfragen mit konsistenter Einrückung, Zeilenumbrüchen und klar sichtbaren Klauseln. SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, CTEs und Unterabfragen werden leichter lesbar, was Reviews, Debugging, Schulung und die Analyse langer Reports erleichtert. Formatierung kann auch helfen, versehentliche Kreuzprodukte, unübersichtliche Bedingungen oder falsch platzierte Klammern schneller zu erkennen. Sie ändert jedoch nicht die Datenbanklogik, optimiert keine Ausführungspläne und garantiert keine Portabilität zwischen Dialekten wie MySQL, PostgreSQL, SQL Server oder Oracle. Für produktive Änderungen müssen Parameterisierung, Berechtigungen, Indizes, Transaktionen und Query-Plan weiterhin geprüft werden. Besonders bei produktiven Daten oder Codebasen sollte das Ergebnis anschließend mit Parser, Tests oder Projektregeln geprüft werden.
Anleitung
Anleitung
- SQL-Anweisungen in das linke Eingabefeld einfügen oder eingeben
- Einrücktiefe (2 Leerzeichen, 4 Leerzeichen oder Tabulator) und Schlüsselwort-Schreibweise wählen
- Auf 'Formatieren' klicken, um SQL zu verschönern, oder 'Komprimieren', um Leerzeichen zu entfernen.
- Ergebnisse erscheinen rechts mit Syntaxhervorhebung
- Auf 'Kopieren' oder 'Herunterladen' klicken, um die Ergebnisse zu speichern.
Hinweise zur SQL-Prüfung
- Formatierung verbessert die Lesbarkeit, prüft jedoch weder Berechtigungen, Indizes, Ausführungspläne noch fachliche Korrektheit.
- Vor der Ausführung geänderter SQL-Statements sollten generierte Klauseln, Zeichenketten, Kommentare und datenbankspezifische Syntax manuell geprüft werden.
Anwendungsfälle
Technisches Prinzip
Die Druckerstufe wendet eine Regel pro Klausel an: SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT beginnen jeweils eine neue Zeile an Spalte 0, projizierte Spalten und ON-Bedingungen rücken eine Ebene ein (2 Leerzeichen, 4 Leerzeichen oder Tabulator), JOIN-Schlüsselwörter (INNER / LEFT / RIGHT / FULL / CROSS) richten sich unter FROM aus, CASE / WHEN / THEN / ELSE / END werden vertikal gestapelt, und geklammerte Unterabfragen sowie CTEs innerhalb von WITH erhalten eine zusätzliche Einrückungsebene, sodass das äußere SELECT visuell verankert bleibt. Zeichenkettenliterale, Zeilenkommentare (-- ...), Blockkommentare (/* ... */) und Dollar-quoted-Blöcke werden einmal tokenisiert und unverändert durchgereicht, sodass die interne Formatierung nie angetastet wird.
Die Schlüsselwort-Schreibweise wird beim Drucken angewendet, nicht durch blindes Regex über den Quelltext — nur Tokens, die als RESERVED_KEYWORD klassifiziert sind, werden in Groß- oder Kleinbuchstaben umgewandelt, sodass ein Bezeichner namens 'order' oder 'user' innerhalb von Backticks seine ursprüngliche Schreibweise behält. Die Dialektunterstützung ist wichtig, weil sich die Liste reservierter Wörter je nach Datenbankengine unterscheidet: PostgreSQL erkennt DISTINCT ON, RETURNING, ILIKE; MySQL fügt IFNULL, LIMIT n,m, ENGINE= hinzu; SQL Server verwendet TOP n, OUTPUT, eckige Klammern für Bezeichner; Oracle ergänzt DUAL, ROWNUM, MINUS statt EXCEPT; BigQuery und Snowflake erweitern den Standard um QUALIFY, EXCEPT (Spalten) und Array-/Struct-Literale. Die Performance ist linear zur Quelltextlänge (O(n) Tokens, O(n) Ausgabebytes), sodass selbst mehrere Megabyte große Migrationsskripte in Millisekunden formatiert werden.
- Tokenizer: zerlegt den Quelltext in die Klassen RESERVED_KEYWORD, IDENTIFIER, STRING_LITERAL, NUMBER, OPERATOR, LINE_COMMENT (-- ...), BLOCK_COMMENT (/* ... */) und WHITESPACE; Kommentare und Zeichenketten werden wörtlich beibehalten
- Dialekterkennung: einfache Anführungszeichen (ANSI), Backtick-Bezeichner (MySQL), eckige Klammern (SQL Server), doppelte Anführungszeichen (PostgreSQL/Standard), Dollar-quoted-Blöcke $$...$$ (PostgreSQL)
- Klausel-Layout: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT verankern jeweils bei Spalte 0; projizierte Spalten und ON-Bedingungen rücken eine Ebene ein; JOIN-Schlüsselwörter richten sich unter FROM aus
- CTE- und Unterabfragen-Einrückung: WITH-Klauseln rücken das innere SELECT eine zusätzliche Ebene ein; korrelierte Unterabfragen innerhalb von EXISTS / IN / Skalarkontexten erhalten ihre eigene Einrückung, sodass die äußere Abfrage verankert bleibt
- Schreibweise-Regel: wird beim Drucken pro Token-Klasse angewendet — nur RESERVED_KEYWORD-Tokens werden groß-/kleingeschrieben, sodass Bezeichner wie `order` oder [user] ihre ursprüngliche Schreibweise behalten
- Bind-Parameter: Fragezeichen-Platzhalter (MySQL Prepared Statements), Dollar-1/Dollar-2-nummerierte Binds (PostgreSQL) und Doppelpunkt-Namen-Binds (Oracle/SQL*Plus) werden als PARAMETER tokenisiert und nie als Bezeichner umformatiert
- Komplexität: O(n) Lexing und O(n) Drucken, wobei n = Quelltextlänge — mehrere Megabyte große Migrationsskripte werden in Millisekunden formatiert; vergleichbar mit der sql-formatter npm-Bibliothek, pgFormatter und dem Prettier SQL Plugin
Beispiele
Dichtes SELECT mit JOIN und WHERE formatieren
Eingabe: select u.id,u.name,o.total from users u left join orders o on o.user_id=u.id where u.status='active' and o.created_at>='2026-01-01' order by o.total desc limit 10;
Ausgabe:
SELECT u.id, u.name, o.total
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 'active'
AND o.created_at >= '2026-01-01'
ORDER BY o.total DESC
LIMIT 10;Formatiertes SQL für eine Konfigurationszeichenkette minifizieren
Eingabe (formatiert, 6 Zeilen):
SELECT id, name
FROM products
WHERE price < 100
AND stock > 0
ORDER BY name;
Minifizierte Ausgabe (1 Zeile, 78 Zeichen):
SELECT id,name FROM products WHERE price<100 AND stock>0 ORDER BY name;WITH (CTE) + verschachtelte Unterabfrage formatieren
WITH recent_orders AS (
SELECT user_id, SUM(total) AS spend
FROM orders
WHERE created_at >= NOW() - INTERVAL '30 days'
GROUP BY user_id
)
SELECT u.name, r.spend
FROM users u
JOIN recent_orders r ON r.user_id = u.id
WHERE r.spend > (SELECT AVG(spend) FROM recent_orders);Schlüsselwörter klein schreiben (Team-Stil)
Einstellungen: Einrückung = 2 Leerzeichen, Schlüsselwörter = Kleinbuchstaben
Eingabe: SELECT * FROM Users WHERE Status=1;
Ausgabe:
select *
from users
where status = 1;
Verwendung: passt zu Migrationsdateien im Stil von Ruby on Rails / Django ORMFAQ
Welche SQL-Dialekte werden unterstützt?
Standardisiertes ANSI SQL plus übliche dialektspezifische Schlüsselwörter: MySQL, PostgreSQL, MSSQL/T-SQL, SQLite, Oracle, BigQuery, Snowflake. Wähle deinen Zieldialekt aus dem Dropdown, damit der Formatter die dialektspezifischen Schlüsselwörter kennt (LIMIT vs. TOP, RETURNING, MERGE usw.).
Welche Stiloptionen stehen zur Verfügung?
Schlüsselwörter in Groß- oder Kleinschreibung, Einrückungstiefe, führende oder nachgestellte Kommas in Spaltenlisten, maximale Zeilenlänge zum Umbrechen und ob vor oder nach Schlüsselwörtern umgebrochen werden soll. Die Optionen werden meist in einem Seitenpanel angezeigt.
Validiert das Tool das SQL?
Die meisten Formatter parsen großzügig und lassen fragwürdiges SQL unverändert durch. Echte Validierung erfordert eine Datenbankverbindung (oder zumindest einen echten SQL-Parser wie sqlparse oder sqlglot). Verwende dieses Tool für die Formatierung; nutze deine IDE oder die Datenbank für die Syntaxprüfung.
Formatiert es Stored Procedures und Trigger?
Die meisten Builds verarbeiten CREATE PROCEDURE, CREATE FUNCTION und Trigger im Rahmen dessen, was der Dialekt unterstützt. Sehr lange Bodies mit Kontrollfluss (IF/ELSE/WHILE) werden korrekt formatiert; Hersteller-Erweiterungen (T-SQL-spezifische Schlüsselwörter) brauchen den passenden Dialekt.
Wird mein Query hochgeladen?
Nein. Die Formatierung läuft in deinem Browser über einen JavaScript-SQL-Parser. Eingefügtes SQL wird nicht übertragen. Trotzdem solltest du in keinem Web-Tool echte Produktions-Zugangsdaten oder personenbezogene Daten einfügen.
Warum sind meine CTEs und JOINs seltsam eingerückt?
Verschiedene Formatter sind sich beim CTE-Layout uneinig. Einige rücken jede CTE-Definition ein, andere richten sie linksbündig aus. Bei JOINs gibt es ähnlich mehrere zulässige Stile ('JOIN x ON' vs. 'JOIN x\n ON'). Wähle die Option, die zum Stil deines Teams passt, und bleibe dabei.
Kann das Tool SQL minifizieren?
Manche Builds bieten einen 'Einzeilen'-Modus, der Zeilenumbrüche und überflüssige Leerzeichen entfernt. Praktisch, um SQL als String-Literal in Code einzubetten. Halte trotzdem die formatierte Version in der Versionsverwaltung – einzeiliges SQL lässt sich beim Code-Review kaum lesen.