SQL-Formatter
SQL für PostgreSQL, MySQL, SQLite und mehr formatieren und verschönern.
Über dieses Tool
Füge eine Abfrage ein, selbst einen langen Einzeiler aus einem Log, und erhalte sie mit einer Klausel pro Zeile. Wähle SQL-Dialekt, Schreibweise der Schlüsselwörter und Einrückung.
So verwendest du es
- Füge eine Abfrage ein, zum Beispiel einen langen Einzeiler aus einem Log oder einer ORM-Debug-Ausgabe.
- Wähle deinen Datenbank-Dialekt, damit seine Schlüsselwörter und seine Syntax erkannt werden.
- Wähle die Schreibweise der Schlüsselwörter (GROSS, klein oder wie eingegeben) und die Einrückung, oder Eine Zeile, um alles zu verdichten.
- Kopiere die formatierte Abfrage.
Fragen
- Welche Datenbanken werden unterstützt?
- Standard-SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL und Trino/Presto.
- Ändert das Formatieren, was die Abfrage tut?
- Nein. Nur Leerraum und, wenn du willst, die Schreibweise der Schlüsselwörter ändern sich. Bezeichner, String-Literale und die Logik der Abfrage bleiben genau, wie sie waren.
- Kann ich mehrere Anweisungen auf einmal formatieren?
- Ja. Trenne sie mit Semikolons, dann wird jede Anweisung einzeln formatiert, mit einer Leerzeile dazwischen.
- Wird meine Abfrage irgendwohin gesendet?
- Nein. Das Formatieren läuft in deinem Browser, daher verlassen Abfragen mit Tabellennamen oder Daten aus der Produktion nie deinen Rechner.
- Prüft der SQL-Formatter meine Abfrage auf Fehler?
- Nein. Er ordnet die Tokens an, validiert die Abfrage aber nicht gegen eine Datenbank oder ein Schema, deshalb wird select a, from t klaglos formatiert. Fehler erscheinen nur, wenn sich der Text im gewählten Dialekt gar nicht lesen lässt. Führe die Abfrage aus oder lass sie per EXPLAIN analysieren, um echte Fehler zu finden.
- Ist „Eine Zeile“ sicher für Abfragen mit -- als Kommentar?
- Nicht immer. Ein Kommentar mit -- reicht bis zum Zeilenende; sobald die Abfrage auf eine Zeile zusammengezogen ist, wird also alles nach dem Kommentar Teil davon. Entferne Kommentare mit -- oder schreib sie als /* … */ um, bevor du „Eine Zeile“ verwendest. Blockkommentare sind auch in einer einzigen Zeile sicher.
- Kann ich dbt-Modelle oder anderes SQL mit Templates formatieren?
- Nicht direkt. Template-Tags in doppelten geschweiften Klammern sowie Steuerblöcke wie if und for sind kein SQL, deshalb bricht der Formatter beim ersten Tag mit einem Parse-Fehler ab. Kompiliere das Modell zuerst, zum Beispiel mit dbt compile, und formatiere das erzeugte SQL.
Was macht ein SQL-Formatter?
Ein SQL-Formatter schreibt eine Abfrage so um, dass ihre Struktur sichtbar wird. Jede Klausel wie SELECT, FROM, JOIN, WHERE, GROUP BY und ORDER BY beginnt in einer eigenen Zeile, die Spalten und Bedingungen darunter werden eingerückt, und Klammern öffnen einen eingerückten Block. Ein Einzeiler wie select id, email from users where active = true and (plan = 3 or trial = true) wird zu einem Dutzend kurzer Zeilen, in denen du siehst, welche Bedingungen zusammengehören.
Die Schreibweise der Schlüsselwörter ist Konventionssache. GROSS ist der traditionelle Stil, der Schlüsselwörter von Tabellen- und Spaltennamen abhebt, klein ist in neueren Styleguides und Analytics-Teams verbreitet, und „Wie eingegeben“ lässt die Schlüsselwörter unangetastet, wenn du nur das Layout korrigieren willst. Wähle 2 oder 4 Leerzeichen Einrückung oder „Eine Zeile“, um eine Abfrage für einen String im Code oder eine Logsuche zu verdichten. SQL-Kommentare bleiben in der Ausgabe erhalten.
SQL lässt sich nicht formatieren? „Parse error: Unexpected“ beheben
Der SQL-Formatter liest die Abfrage nach den Regeln des gewählten Dialekts, daher führt Syntax einer anderen Datenbank zu einem Fehler wie „Parse error: Unexpected … at line 1 column 8“. Bezeichner in Backticks wie `order` sind Syntax von MySQL, MariaDB, BigQuery und Spark und scheitern unter PostgreSQL oder SQL Server. Eckige Klammern wie [order] gehören zu SQL Server und scheitern unter MySQL. Wähle den Dialekt, für den die Abfrage geschrieben wurde, dann verschwindet der Fehler meist.
Auch Platzhalter hängen vom Dialekt ab. Ein ? aus JDBC oder einem MySQL-Treiber funktioniert in Standard-SQL, MySQL, PostgreSQL und SQLite, $1 funktioniert in PostgreSQL, und SQL Server erwartet benannte Parameter wie @id, dort stoppt ein ? also den Formatter. Template-Tags aus dbt oder anderen Jinja-basierten Tools sind überhaupt kein SQL und verursachen beim ersten Tag einen Parse-Fehler. Formatiere stattdessen die kompilierte Abfrage.
SQL-Stil: Best Practices für lesbare Abfragen
Formatieren bringt das Layout in Ordnung, und ein paar Gewohnheiten machen Abfragen leichter zu reviewen. Schreib explizite JOIN … ON, statt Tabellen mit Kommas in FROM aufzulisten, gib Tabellen kurze, sprechende Aliasse wie u für users und o für orders, und nenne die Spalten, die du brauchst, statt SELECT *. Common Table Expressions mit WITH … AS zerlegen eine lange Abfrage in benannte Schritte, die sich von oben nach unten lesen.
Halte pro Repository ein einheitliches SQL-Format ein: derselbe Dialekt, dieselbe Schreibweise der Schlüsselwörter und dieselbe Einrückung, damit Umformatieren nie Rauschen ins Code-Review bringt. Um zwei Versionen einer langen Abfrage zu vergleichen, formatiere beide hier mit identischen Einstellungen und füge sie dann in den Textvergleich ein. Ohne diesen Schritt erscheint ein verschobener Zeilenumbruch als Unterschied, obwohl die Abfrage selbst gleich ist.
Funktioniert etwas nicht, oder sieht ein Ergebnis falsch aus? Ein Problem mit diesem Tool melden