SQL Query Formatter

Der SQL Query Formatter für 16 Dialekte, komplett in deinem Browser – er beweist danach, dass sich nur Whitespace geändert hat, und sagt dir, was an der Query falsch ist, die er gerade aufgeräumt hat.

Kostenlos · Ohne Anmeldung · Nichts verlässt deinen Browser

Formatiert beim Tippen für 16 Dialekte, komplett in deinem Browser. Dann kommt der Teil, den andere Formatter auslassen: Es belegt, dass sich nur Whitespace geändert hat, und sagt dir, was an der eben aufgeräumten Query nicht stimmt.

Keywords
Einrückung

1 Zeile · 203 Zeichen

18 Zeilen · 247 Zeichen

  • OKGeprüft – nur Whitespace hat sich geändert

    Alle 48 Token deiner Query haben das Formatieren unverändert überstanden. Jedes String-Literal ist Byte für Byte gleich, jeder Identifier, jede Zahl, jeder Operator, in derselben Reihenfolge – hier in deinem Browser geprüft, nicht angenommen. Nur Whitespace und die Schreibweise der Keywords unterscheiden sich.

Was an dieser Query nicht stimmt

  • WarnungSELECT * über einen Join

    Jede Spalte jeder verknüpften Tabelle kommt zurück, doppelte Join-Keys eingeschlossen, und das Ergebnis ändert seine Form, sobald jemand eine Spalte hinzufügt. Nenn die Spalten, die du brauchst.

  • WarnungLIKE-Muster, das mit % beginnt

    Eine Wildcard am Anfang kann keinen normalen B-Tree-Index nutzen, also durchsucht das die ganze Tabelle, egal wie gut die Spalte indiziert ist. Für Teilstring-Suche in jeder Größe hilft ein Volltext- oder Trigram-Index.

  • WarnungNOT IN über eine Subquery

    Liefert die Subquery auch nur ein NULL, gibt NOT IN gar keine Zeilen zurück – keinen Fehler, nur ein leeres Ergebnis, das wie eine gültige Antwort aussieht. NOT EXISTS verhält sich so, wie du es erwartest, und ist meist auch schneller.

Das sind lexikalische Prüfungen des Query-Texts. Sie wissen nichts über deine Indizes, deine Zeilenzahlen oder deine Daten – sieh sie also als Stellen, die einen zweiten Blick wert sind, nicht als Urteile.

Aufbau der Query

Statement
SELECT · nur lesend
Tabellen
3 · users, orders, banned_users
Joins
1 · 0 CTEs
Subqueries
1 · 1 Statement

Alles auf dieser Seite läuft in deinem Browser. Die Query wird nirgendwohin gesendet, nie geloggt und nie gespeichert – und das zählt, denn die Queries, die es wert sind, formatiert zu werden, kommen meist aus der Produktion.

Tekk lässt Loops über deine Codebase laufen, die finden, was sich verbessern lässt, und deinem Coding-Agent die Spec übergeben, sobald du es mit Greenlight freigibst – dieselbe Idee wie diese Seite, nur auf eine ganze Änderung angewandt statt auf eine einzelne Query.

So funktioniert’s

  1. 1

    Query einfügen und Dialekt wählen

    Sechzehn stehen zur Wahl, von PostgreSQL und MySQL bis Snowflake, BigQuery, DuckDB und Oracle. Formatiert wird beim Tippen, ohne Absenden-Knopf und ohne Netzwerkanfrage. Nutzt deine Query Syntax aus einem anderen Dialekt – Backticks unter Postgres, SELECT TOP außerhalb von SQL Server –, sagt dieser SQL Query Formatter das und bietet den Wechsel an.

  2. 2

    Prüf die Verifizierungszeile

    Jeder Formatter verspricht stillschweigend, nur Whitespace geändert zu haben. Dieser prüft es. Deine Query und die formatierte Ausgabe werden in signifikante Tokens zerlegt und einzeln verglichen, sodass die Seite dir sagen kann, dass alle 48 Tokens im Beispiel oben identisch geblieben sind, statt dich um Vertrauen zu bitten.

  3. 3

    Lies, was gefunden wurde

    Ein DELETE ohne WHERE, ein Komma-Join, der eigentlich ein Kreuzprodukt ist, ein LIKE, das mit einem Wildcard beginnt, ein NOT IN über eine Subquery, das nichts mehr zurückgibt, sobald eine Zeile NULL ist. Ein Formatter, der nur neu einrückt, überlässt es dir, das selbst zu entdecken.

Was Formatieren versprechen kann und was nicht

Ein Formatter ordnet Whitespace neu. Das ist der ganze Job, und jedes Tool in dieser Kategorie gibt dasselbe stillschweigende Versprechen: Deine Query bedeutet noch, was sie bedeutet hat.

Keines davon zeigt seinen Rechenweg. Du fügst eine Query ein, bekommst eine zurück und entscheidest, ob du ihr traust – meist durch Überfliegen, also genau das, was du mit einem Formatter vermeiden wolltest.

Diese Seite prüft stattdessen. Beide Versionen werden in signifikante Tokens zerlegt – alles, was Bedeutung trägt, ohne Whitespace und Kommentare – und Position für Position verglichen:

Token-Typ Wie verglichen wird
String-Literale Byte für Byte. 'Active' und 'active' sind unterschiedliche Werte.
Identifier, Keywords Ohne Rücksicht auf Groß- und Kleinschreibung – die Schreibung von Keywords ist eine Formatierungsoption.
Zahlen, Operatoren, Satzzeichen Exakt und in Reihenfolge.
Körper in Dollar-Quotes Als ein undurchsichtiges Token. Der Inhalt ist meist kein SQL.

Stimmt jedes Token überein, unterscheidet sich die Ausgabe von deiner Eingabe nur in Whitespace und der Schreibung der Keywords. Das ist eine schmale Garantie, und sie schmal zu formulieren ist der Punkt: Sie sagt, dass sich die Query nicht verändert hat, nicht, dass sie korrekt ist.

Die Checks, und warum genau diese

Das Panel mit den Befunden ist bewusst kurz. Ein Tool, das alles markiert, bringt dir bei, es zu ignorieren, deshalb muss sich jeder Check seinen Platz verdienen, indem das Muster oft genug falsch oder teuer ist, um eine Unterbrechung wert zu sein.

Gefahr – anhalten und hinsehen

  • UPDATE oder DELETE ohne WHERE. Trifft jede Zeile. Ist das gewollt, ist TRUNCATE beim Löschen schneller und sagt es laut.
  • Bedingungsloser Cross Join. Kommagetrennte Tabellen im FROM, ohne dass etwas sie verbindet. Zwei Tabellen mit 10.000 Zeilen liefern 100 Millionen.

Warnung – vermutlich nicht so gemeint

  • Komma-Joins mit WHERE. Erlaubt, aber Join-Bedingungen und Filter stehen durcheinander, und wer eine Zeile aus dem WHERE löscht, macht daraus still ein Kreuzprodukt.
  • SELECT * über einen Join. Jede Spalte jeder Tabelle, doppelte Join-Keys inklusive, und die Form ändert sich, sobald jemand eine Spalte hinzufügt.
  • LIKE '%...'. Ein führender Wildcard kann keinen B-Tree-Index nutzen, also wird die Tabelle gescannt, egal wie gut die Spalte indiziert ist.
  • NOT IN (subquery). Liefert die Subquery ein einziges NULL, gibt das Ganze keine Zeilen zurück – kein Fehler, nur ein leeres Ergebnis, das wie eine Antwort aussieht. NOT EXISTS verhält sich wie erwartet.

Hinweis – gut zu wissen

  • Eine Funktion um eine gefilterte Spalte. WHERE lower(email) = ... verhindert, dass ein einfacher Index auf email genutzt wird. Ein Expression-Index stellt das wieder her.
  • DISTINCT über einen Join. Kaschiert oft einen Join, der Zeilen vervielfacht, statt einen echten Bedarf an eindeutigen Werten zu decken.
  • Großer OFFSET. Die Datenbank läuft trotzdem durch jede übersprungene Zeile und verwirft sie, deshalb kostet Seite 500 viel mehr als Seite 1.

Das sind lexikalische Checks. Sie sehen weder dein Schema noch deine Indizes noch deine Zeilenzahlen, beschreiben also Muster, statt Performance vorherzusagen.

Warum es in deinem Browser läuft

Die Queries, die sich zu formatieren lohnen, stammen aus einem Slow-Query-Log oder der Debug-Ausgabe eines ORMs. Sie enthalten Tabellennamen, Spaltennamen und oft literale Werte aus Produktionsdaten.

Das an einen Server zu schicken, nur damit dort der Whitespace umsortiert wird, ist ein schlechter Tausch. Die Engine – etwa 76 KB – wird bei deinem ersten Tastendruck auf deinen Rechner geladen, und danach passiert alles lokal. Es gibt keine Anfrage, die man mitlesen könnte, kein Log, das leaken kann, und kein Konto, das daran hängt.

Die Query, die du vor dem Tippen formatiert siehst, wird beim Build berechnet, die Seite ist also beim Laden vollständig, statt leer zu bleiben, während etwas lädt.

Häufige Fragen

Wird meine Query gespeichert oder irgendwohin gesendet?
Nein. Die Formatierungs-Engine wird beim ersten Bearbeiten der Query in deinen Browser geladen, und alles danach – Formatieren, Token-Vergleich, Befunde – passiert auf deinem Rechner. Nichts wird hochgeladen, geloggt oder gespeichert, und es gibt kein Konto. Gut zu wissen, denn die Queries, bei denen sich das Formatieren wirklich lohnt, kommen meist aus der Produktion.
Ändert das Formatieren jemals, was meine Query tut?
Sollte es nicht, und diese Seite prüft das, statt es anzunehmen. Beide Versionen werden in signifikante Tokens zerlegt – String-Literale Byte für Byte, Identifier und Keywords ohne Rücksicht auf Groß- und Kleinschreibung, weil die eine Formatierungsoption ist – und Position für Position verglichen. Weicht ein einziges Token ab, bekommst du statt eines grünen ein rotes Panel, das es benennt.
Welche Dialekte werden unterstützt?
Standard SQL, PostgreSQL, MySQL, MariaDB, SQL Server (T-SQL), SQLite, BigQuery, Snowflake, Redshift, Spark, Trino, DuckDB, ClickHouse, Oracle PL/SQL, Hive und Db2. Der falsche Dialekt ist der übliche Grund, warum die Ausgabe seltsam aussieht, deshalb wird dialektspezifische Syntax erkannt und markiert.
Warum markiert er Probleme, statt nur zu formatieren?
Weil du dir die Query sowieso gerade ansiehst. Ein DELETE ohne WHERE ist ein Fix von dreißig Sekunden, solange er auf dem Bildschirm steht, und ein sehr langer Nachmittag, wenn er gelaufen ist. Ein SQL Query Formatter ist das Letzte, was eine Query berührt, bevor sie läuft – also der richtige Ort, etwas zu sagen. Die Checks sind bewusst zurückhaltend: Sie schlagen bei Mustern an, die oft genug falsch oder teuer sind, um eine Unterbrechung wert zu sein, nicht bei jeder Stilfrage.
Worauf prüft er genau?
UPDATE oder DELETE ohne WHERE, Komma-Joins und bedingungslose Kreuzprodukte, SELECT * über einen Join, LIKE-Muster mit führendem Wildcard, NOT IN über eine Subquery, Funktionen um gefilterte Spalten, DISTINCT, das einen Join mit vervielfachten Zeilen verdeckt, und Paginierung mit großem OFFSET. Zu jedem gibt es den Fix, nicht nur den Hinweis auf den Code Smell.
Sind die Warnungen verlässlich?
Es sind lexikalische Checks auf dem Query-Text, sie wissen also nichts über deine Indizes, Zeilenzahlen oder Datenverteilung. Nimm sie als Stellen, die einen zweiten Blick wert sind, nicht als Urteile. Sie sagen dir nicht, dass eine Query langsam ist – sie sagen dir, dass sie ein Muster enthält, das oft langsam ist, und das ist eine andere und ehrlichere Aussage.
Behält dieser SQL Beautifier meine Kommentare?
Ja, Zeilen- und Blockkommentare, an Ort und Stelle. Das prüft bei jedem Build ein Test, statt es dem Zufall zu überlassen, denn ein SQL Beautifier, der still den Kommentar frisst, der erklärt, warum ein Join existiert, würde aktiv schaden.
Kommt er mit CTEs, Window Functions und Subqueries klar?
Ja. Verschachtelte CTEs, Window Functions mit eigenem PARTITION BY und ORDER BY, lange IN-Listen, CASE-Ausdrücke, UNION und Funktionskörper in Dollar-Quotes werden alle verarbeitet, und für jeden Fall prüft ein Test, dass die Tokens überleben. Genau dort zerlegt ein halbfertiger Parser still etwas.
Warum hakt die Seite beim ersten Tippen kurz?
Sie lädt die Formatierungs-Engine – etwa 76 KB –, die niemand bekommt, der die Seite nur lesen wollte. Die formatierte Query, die du vor dem Tippen siehst, wird beim Build berechnet, die Seite ist also nie leer, während sie wartet.
Gibt es ein Limit oder einen Bezahltarif?
Nein. Es gibt nichts zu messen, weil nichts auf unseren Servern läuft – SQL hier online zu formatieren kostet uns nichts pro Nutzung, also gibt es kein Run-Limit, keine Anmeldeschranke und keinen Upsell im Tool.
Was unterscheidet ihn von anderen SQL-Formattern online?
Die meisten formatieren und hören auf. Dieser SQL Query Formatter ergänzt zwei Dinge: den Beweis auf Token-Ebene, dass die Bedeutung erhalten blieb, und das Panel mit den Befunden. Wenn du nur neu einrücken willst, reicht jeder Online-Formatter; der Unterschied zeigt sich, wenn mit der Query etwas nicht stimmt.
Kann ich die Ausgabe in einer Migration verwenden?
Die Verifizierung deckt genau eine Sache ab: Die formatierte Ausgabe enthält dieselben Tokens wie deine Eingabe, in derselben Reihenfolge. Das ist eine echte Garantie und eine schmale. Sie sagt, dass sich die Query nicht verändert hat – nicht, ob die Query von vornherein richtig war.
Warum ist das kostenlos, und was ist Tekk?
Tekk macht dein Produkt zu Software, die sich selbst verbessert: 16 Loops beobachten deine Codebase, bringen dir Proposals, die du mit Greenlight freigibst oder ablehnst, und dein Coding-Agent baut das Ergebnis. Zu prüfen, ob eine Änderung getan hat, was sie behauptet, statt ihr einfach zu vertrauen, ist dieselbe Idee wie bei diesem SQL Beautifier, nur auf eine ganze Codebase angewendet. Diese Seite kostet nichts im Betrieb, und es gibt keinen Upsell darin.

Verwandte Tools

Tool Code Explainer Tool Base64 Decode Tool JSON formatieren Tool XML Formatter Tool Slug Generator Tool Unix Timestamp Converter

Willst du eine echte Spec für das, was du baust?

Schreib einen Satz. Tekk liest deinen Code und schreibt die Spec, die dein Coding-Agent baut – und seine Loops behalten im Blick, was du auslieferst.

Kostenlos testen · GitHub bei der Registrierung verbinden