Skip to main content

SQL-Formatierer

SQL-Abfragen formatieren und verschönern mit Schlüsselwort-Großschreibung.

Geprüft von · Zuletzt geprüft

So wird der SQL-Formatierer verwendet

  1. Füge deine Abfrage in den Eingabebereich ein. SELECT-Anweisungen, datenmodifizierende INSERT/UPDATE/DELETE, DDL wie CREATE TABLE und durch Semikolons getrennte Mehrfachanweisungsskripte werden alle akzeptiert.
  2. Wähle die Einrückungstiefe: 2 Leerzeichen (üblich in PostgreSQL- und MySQL-Team-Stilen) oder 4 Leerzeichen (Oracle SQL Developer Standard).
  3. Klicke auf Formatieren. Schlüsselwörter werden großgeschrieben, Klauselgrenzen erhalten Zeilenumbrüche, und Unterabfragen innerhalb von Klammern werden eine Ebene tiefer eingerückt, sodass Verschachtelungen auf einen Blick sichtbar sind.
  4. Kopiere das Ergebnis zurück in deinen Abfrage-Runner, dein BI-Tool oder deinen Pull Request. Der Formatierer bewahrt Zeichenkettenliterale und Bezeichner, sodass deine Abfrage dieselben Zeilen zurückgibt.

Was unter der Haube passiert

Der Formatierer arbeitet mit Tokens statt mit einem SQL-Parsebaum. Er durchläuft die Abfrage Zeichen für Zeichen und verfolgt Zeichenkettenliterale, Bezeichner-Anführungszeichen (", \`, [ ]) und Klammertiefe. Wenn er auf ein Hauptklausel-Schlüsselwort trifft - SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION, WITH und die Join-Varianten - gibt er einen Zeilenumbruch aus und richtet das Schlüsselwort an der aktuellen Einrückung aus. Join-Bedingungen, die mit ON beginnen, bleiben auf der folgenden Zeile, damit der Tabellenname in der Join-Zeile sichtbar bleibt.

Die Groß-/Kleinschreibungskonvertierung schreibt jedes reservierte Wort, das in der Token-Liste erkannt wird, groß, während Bezeichner und Zeichenketteninhalte unverändert bleiben. Groß-/Kleinschreibung in Anführungszeichen-Bezeichnern wird erhalten, weil in PostgreSQL und standardkonformen Datenbanken "Users" und "users" verschiedene Tabellen sind. Das Tool versucht nicht, dialektspezifische Features wie MySQL-USE INDEX-Hinweise, PostgreSQL-LATERAL-Joins oder SQL-Server-MERGE-Anweisungen als speziell eingerückte Konstrukte zu erkennen - sie werden verbatim erhalten und nach Klammertiefe eingerückt.

Wann dieses Tool hilft

  • Eine generierte Abfrage aus einem ORM (Prisma, SQLAlchemy, ActiveRecord) für manuelle Inspektion bei einer Slow-Query-Untersuchung lesbar machen.
  • Eine Abfrage für einen Pull Request oder eine Migrationsdatei vorbereiten, bei der die Einrückung die logische Struktur zeigt.
  • Lange Analytics-Abfragen lesen, die aus Looker-, Tableau- oder Metabase-Logs gezogen wurden.
  • Abfragen innerhalb von Kommentaren oder Docstrings formatieren, bei denen deine IDE nicht weiß, wie sie SQL verarbeiten soll.
  • Eine stringifizierte Abfrage aus Anwendungs-Logs in eine lesbare Form zurückbringen, bevor sie erklärt wird.
  • SQL lehren: Großbuchstaben-Schlüsselwörter lassen die Grammatik für Lernende hervorspringen, die ein Beispiel scannen.

Randfälle und Grenzen

  • Window-Funktionen. OVER (PARTITION BY x ORDER BY y) wird korrekt formatiert, weil die Partition- und Reihenfolge-Klauseln innerhalb der Klammern leben und nach Tiefe eingerückt werden. Sehr lange Window-Definitionen umbrechen möglicherweise nicht so schön wie ein dialektbewusster Formatierer.
  • CTEs. WITH cte AS (...) erhält einen Zeilenumbruch bei der öffnenden Klammer und rückt das innere Select ein. Mehrere CTEs, durch Kommas getrennt, erhalten je einen eigenen Block.
  • Zeichenketten mit Schlüsselwörtern. Ein Literal wie 'select your language' wird unberührt gelassen, weil der Tokenizer den Zeichenkettenstatus verfolgt. Groß-/Kleinschreibung innerhalb von Zeichenketten wird nie geändert.
  • Kommentare. Einzeilige ---Kommentare und Block-/* ... */-Kommentare werden erhalten, landen aber möglicherweise nicht auf der exakten Zeile, auf der sie ursprünglich standen, wenn sie in der Mitte einer Klausel stehen.
  • Dynamisches SQL. Abfragen, die durch Zeichenkettenverkettung im Anwendungscode erstellt werden, enthalten oft Platzhalter wie ? oder $1. Diese werden als einfache Bezeichner behandelt und unverändert durchgeleitet.

SQL-Standards-Kontext

SQL ist als ISO/IEC 9075 standardisiert. Die am häufigsten zitierten Ausgaben sind SQL:1999 (gemeinsame Tabellenausdrücke, rekursive Abfragen, Trigger), SQL:2003 (Window-Funktionen, XML-Features), SQL:2008 (TRUNCATE, INSTEAD OF-Trigger) und SQL:2016 (JSON-Funktionen, Zeilenmuster-Erkennung). In der Praxis liefert jede Datenbank einen eigenen Dialekt mit Erweiterungen, sodass eine Abfrage, die hier korrekt formatiert wird, nicht automatisch zwischen PostgreSQL, MySQL und SQL Server portierbar ist. Schlüsselwörter wie LIMIT (PostgreSQL/MySQL/SQLite), TOP (SQL Server) und FETCH FIRST (Standard) tun alle ähnliche Dinge, sind aber nicht austauschbar. Schlüsselwörter großzuschreiben ist eine stilistische Konvention, keine Anforderung - ANSI SQL ist nicht case-sensitiv für Schlüsselwörter - aber es macht Abfragen einfacher zu scannen und entspricht den Konventionen in jedem großen SQL-Lehrbuch.

Vergleich mit anderen Formatierern

Dedizierte Tools wie sql-formatter und pgFormatter bauen tatsächlich Parsebäume auf und unterstützen dialektspezifische Schlüsselwörter, Ausrichtung von SELECT-Spalten und Kommentierungskonventionen, die ein regex-basierter Formatierer nicht leisten kann. Wenn du täglich SQL formatierst, installiere einen dieser als Editor-Erweiterung. IDE-integrierte Formatierer wie die in DataGrip oder DBeaver sind ebenfalls ausgezeichnet, weil sie das Schema deiner Verbindung kennen und mehrstufige CTE-Abfragen schön einrücken können. Dieses browserbasierte Tool ist für den einmaligen Fall: Du hast eine Abfrage aus einem Log oder von einem Kollegen, möchtest sie lesen und willst keine vollständige IDE öffnen. Für die Stilerzwingung in der Produktion checke die Abfrage in ein Repository ein und führe einen echten Formatierer als Teil der CI aus.

Häufig gestellte Fragen

Parst dieser Formatierer SQL semantisch?

Nein. Es ist ein Token-Level-Formatierer, der etwa 80 reservierte Schlüsselwörter erkennt und Klammern, Zeichenketten und Bezeichner-Anführungszeichen verfolgt. Er erstellt keinen abstrakten Syntaxbaum und kann daher nicht überprüfen, ob die Spalten, die du auswählst, tatsächlich in den Tabellen existieren, denen du beitrittst. Das macht ihn äußerst tolerant gegenüber Dialektunterschieden - PostgreSQL-, MySQL-, SQL-Server-, Oracle-, SQLite-, Redshift-, Snowflake-, BigQuery-Abfragen alle passieren - bedeutet aber auch, dass er keine tiefe Umformatierung wie das Ausrichten von <code>SELECT</code>-Spalten oder das Umbrechen langer <code>WHERE</code>-Klauseln vornehmen kann.

Ändert er das Ergebnis meiner Abfrage?

Nein. Formatierung ändert nur Leerzeichen und Groß-/Kleinschreibung der Schlüsselwörter. SQL-reservierte Wörter sind gemäß ANSI-Standard nicht case-sensitiv, sodass die Umschreibung von <code>select</code> zu <code>SELECT</code> für jede Datenbank-Engine keinen Unterschied macht. Zeichenkettenliterale und in Anführungszeichen gesetzte Bezeichner bleiben byte-für-byte identisch. Das Ausführen der formatierten Abfrage gibt exakt die gleichen Zeilen zurück wie die Ausführung der ursprünglichen.

Wird mein SQL je hochgeladen?

Nein. Der Formatierer ist eine Preact-Komponente, die mit dem Seiten-Bundle ausgeliefert wird und vollständig in deinem Browser-Tab läuft. Die Format-Schaltfläche ruft eine lokale JavaScript-Funktion auf; es gibt kein fetch oder Websocket zu einem entfernten Dienst. Da Leute oft Abfragen einfügen, die Schema-Namen, Tabellennamen und Literal-Beispieldaten enthalten, ist diese Nur-lokal-Garantie wichtig - nichts, was du einfügst, erreicht irgendeinen Server.

Wie werden Unterabfragen eingerückt?

Jede öffnende Klammer schiebt die Einrückung um eine Ebene, sodass eine Unterabfrage in der <code>FROM</code>-Klausel unter ihrem übergeordneten <code>SELECT</code> ausgerichtet ist. Tief verschachtelte Unterabfragen erhalten proportional tiefere Einrückung, was die Verschachtelung selbst bei Abfragen sichtbar macht, die viele Zeilen umfassen. Dieser Ansatz unterscheidet nicht zwischen einer skalaren Unterabfrage und einer korrelierten Unterabfrage, liest sich aber in beiden Fällen sauber.

Was ist mit dialektspezifischen Features wie PIVOT oder MATCH_RECOGNIZE?

Diese werden verbatim erhalten, aber nicht speziell eingerückt. Der Formatierer erzeugt dennoch lesbare Ausgabe, weil er die erkannten Schlüsselwörter darum herum großschreibt und nach Klammertiefe einrückt. Wenn du häufig mit einem bestimmten Dialekt arbeitest, erzeugt ein dialektbewusster Formatierer wie <code>pgFormatter</code> für PostgreSQL oder ein BigQuery-fähiger Formatierer merklich bessere Ergebnisse für anbieterspezifische Syntax.

Normalisiert er die Bezeichner-Anführungszeichen?

Nein. Wenn deine Quelle Backticks (MySQL-Stil), doppelte Anführungszeichen (ANSI und PostgreSQL) oder eckige Klammern (SQL-Server-Stil) verwendet, lässt der Formatierer sie genau so, wie sie geschrieben wurden. Die Umstellung zwischen Anführungsstilen hat echte semantische Konsequenzen - MySQL-Backticks sind unter Linux nicht case-sensitiv und unter macOS je nach Dateisystem case-sensitiv - daher ist Konservatismus die sicherere Standardeinstellung.

Kann ich ein Skript mit mehreren durch Semikolons getrennten Anweisungen formatieren?

Ja. Der Formatierer behandelt ein Semikolon auf der obersten Ebene als Anweisungsabschluss und fügt danach eine Leerzeile ein, sodass Mehrfachanweisungsskripte lesbare Blöcke erzeugen. Transaktionsanweisungen wie <code>BEGIN</code>, <code>COMMIT</code> und <code>ROLLBACK</code> werden als Schlüsselwörter großgeschrieben, aber nicht speziell mit den Anweisungen gruppiert, die sie einschließen.

Wie geht er mit SQL-Kommentaren um?

Sowohl <code>-- Zeilenkommentare</code> als auch <code>/* Blockkommentare */</code> werden in ihren ursprünglichen Positionen erhalten. Kommentare sind nützliche Markierungen für Schema-Migrationen und zur Dokumentation des Zwecks komplexer CTEs, sodass der Formatierer sie nie entfernt. Ein Zeilenkommentar schiebt jedes Schlüsselwort, das darauf folgt, auf eine neue Zeile, was der Behandlung durch SQL-Parser entspricht.

Soll ich formatiertes SQL in Git committen?

Ja für Migrationen, nein für generierte Abfragen. Handgeschriebene Migrationen und gespeicherte Prozeduren profitieren von konsistenter Formatierung, weil sie von Menschen geprüft werden. Abfragen, die von einem ORM generiert werden, werden zur Laufzeit neu generiert, und sie als formatierte Dateien einzuchecken erzeugt nur Merge-Konflikte. Eine gute Regel: SQL-Quelldateien formatieren, Tool-Ausgaben unformatiert oder nicht eingecheckt lassen.

Warum erscheint mein <code>JOIN</code>-Schlüsselwort manchmal in derselben Zeile wie <code>FROM</code>?

Der Formatierer setzt einen Zeilenumbruch vor die wichtigsten Klausel-Schlüsselwörter, und <code>JOIN</code> zählt als Hauptklausel. Wenn deine Quelle das JOIN bereits in einer neuen Zeile hatte, bleibt es auf einer; wenn das JOIN Teil eines längeren, in Klammern eingeschlossenen Ausdrucks war, behält der Formatierer die Klammertiefe als steuernde Einrückung. Wenn das Ergebnis nicht deinem Team-Stil entspricht, erwäge die Übernahme eines parsebaum-basierten Formatierers, der immer vor jedem JOIN umbricht.

Verwandte Tools

Mehr Developer Tools

AI Token Counter

Count tokens for GPT-4o, Claude, and Gemini models instantly.

Open tool

Base64 Encoder & Decoder

Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.

Open tool

Bulk URL Encode / Decode

Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.

Open tool

chmod Calculator

Calculate and convert Unix file permission modes between octal and symbolic.

Open tool

Code Screenshot

Create beautiful code snippet images with customizable themes.

Open tool

Color Converter

Convert colors between HEX, RGB, HSL and CMYK formats.

Open tool
ZeroUtil unterstützen