Eine Abfrage, die als eine einzige 400-Zeichen-Zeile ankommt, ist unlesbar, und unlesbare Abfragen verstecken Fehler. Dieses Tool parst dein SQL und legt jede Klausel auf eine eigene Zeile. Es parst, statt nur einzurücken — deshalb kann es dir sagen, wenn etwas nicht stimmt, und deshalb ist die Wahl des richtigen Dialekts wichtig.
Die Dialektauswahl ist keine Dekoration
SQL ist ein Standard, den niemand exakt umsetzt, und die Unterschiede fangen bei etwas so Grundlegendem an wie dem Quotieren eines Namens. MySQL und MariaDB umschließen Bezeichner mit Backticks. PostgreSQL nutzt doppelte Anführungszeichen und lehnt Backticks rundweg ab. SQL Server nimmt eckige Klammern. Eine für ein System geschriebene und als anderes geparste Abfrage formatiert nicht bloß seltsam — sie scheitert.
Du kannst das hier sehen. Füge eine MySQL-Abfrage mit Backtick-Spaltennamen ein, wähle PostgreSQL, und die Ausgabe wird leer: Der Parser hat korrekt verweigert, Backticks als PostgreSQL zu lesen, denn das sind sie nicht. Das ist das Werkzeug, das dir etwas Wahres über deine Abfrage sagt, keine Fehlfunktion.
Die Unterschiede reichen tiefer als das Quotieren. Zeilenbegrenzung heißt LIMIT in MySQL, PostgreSQL und SQLite, TOP in SQL Server und FETCH FIRST im tatsächlichen Standard. Zeichenkettenverkettung ist fast überall || und in MySQL CONCAT(), wo || logisches ODER bedeutet, sofern kein bestimmter Modus aktiv ist. Verschiebst du eine Abfrage zwischen Engines, sind das die Fugen, an denen sie reißt.
Formatieren prüft Syntax, nicht Wahrheit
Gib diesem Tool eine Abfrage voller Unsinn, und es zeigt dir einen Fehler, weil es den Text wirklich parst. Das ist nützlich, und es ist zugleich die Grenze dessen, was es dir sagen kann. Eine Abfrage kann tadellos wohlgeformt und trotzdem katastrophal falsch sein.
Es kann nicht wissen, ob deine Tabellen existieren, ob die Spalte, über die du gejoint hast, indiziert ist, ob dieser JOIN die erwarteten Zeilen liefert oder fünfzig Millionen. Sauberes Formatieren ist kein Code-Review. Was Formatieren dir bringt, ist die Möglichkeit, die Form der Abfrage zu sehen — und einmal ausgelegt, wird eine fehlende Join-Bedingung oder eine WHERE-Klausel, die ihre Klammern verloren hat, sichtbar, wie sie es auf einer langen Zeile nie ist.
Ein Formatierer ist kein Sicherheitswerkzeug
Das gehört klar gesagt, denn die Verwechslung ist real. Dein SQL zu formatieren tut rein gar nichts gegen SQL-Injection. Es maskiert nichts, es validiert nichts, und eine Abfrage, die durch Zusammenkleben von Benutzereingaben in eine Zeichenkette entsteht, ist formatiert exakt so gefährlich wie unformatiert — sie ist nur leichter zu lesen, während sie deine Tabelle löscht.
Die einzige echte Verteidigung sind parametrisierte Abfragen: SQL-Text und Werte reisen getrennt, ein Wert kann also nie als Syntax umgedeutet werden. Jeder gängige Treiber unterstützt das. Greifst du nach einer Escaping-Funktion, ist das meist ein Zeichen, dass die Abfrage falsch herum gebaut wird.
Schlüsselwörter sind case-insensitiv; Bezeichner sind die Falle
SELECT, select und SeLeCt sind für jede Engine dasselbe Schlüsselwort, die Großschreiboption hier ist also reiner Stil — eine verbreitete Konvention, die die Struktur überfliegbar macht, mehr nicht. Niemand wird dir für kleingeschriebene Schlüsselwörter danken, und kaputtgehen wird auch nichts.
Bei der Schreibweise von Bezeichnern wohnen die echten Fehler. PostgreSQL klappt nicht quotierte Bezeichner auf Kleinschreibung, SELECT MyColumn fragt also tatsächlich nach mycolumn — und hast du die Spalte als "MyColumn" mit Anführungszeichen angelegt, wird sie nicht gefunden. Der Standard sagt, Bezeichner klappen auf Großschreibung, PostgreSQL ist hier also formal nicht konform, und alle haben sich stillschweigend darauf geeinigt, damit zu leben.
MySQL ist noch seltsamer: Ob Tabellennamen case-sensitiv sind, hängt vom Dateisystem unter dem Server ab. Tabellen sind Dateien, also sind sie unter Linux case-sensitiv und unter Windows und macOS nicht. Das ist der Mechanismus hinter einer speziellen, elenden Fehlerklasse — eine Abfrage, die auf dem Mac eines Entwicklers läuft und in der Linux-Produktion scheitert, ohne dass irgendetwas im Code das erklärt.
Häufige Fragen
Wird meine Abfrage an einen Server geschickt?
Nein. Dieses Tool ist als "client" gekennzeichnet: Der Parser läuft in deinem Browser-Tab, das SQL verlässt das Gerät nie. Das wiegt hier schwerer als bei den meisten Tools, denn echte Abfragen tragen Tabellennamen, Spaltennamen und oft wörtliche Werte aus der Produktion — die Form deines Schemas ist Information, die du einem Fremden vermutlich nicht überlassen willst.
Ändert Formatieren, was meine Abfrage tut?
Nein. Whitespace zwischen SQL-Token ist nicht bedeutsam, die umformatierte Abfrage ist also dieselbe Abfrage. Aufpassen muss man einzig bei Zeichenkettenliteralen: Text in Anführungszeichen ist Daten, und ein Formatierer muss ihn unangetastet lassen. Dieser tut das. Begegnet dir je ein Formatierer, der innerhalb einer Zeichenkette neu einrückt, hör sofort auf, ihn zu benutzen.
Warum zeigt meine Abfrage hier einen Fehler, läuft aber in meiner Datenbank?
Höchstwahrscheinlich der Dialekt. Wähle die Engine, die du wirklich nutzt, statt Standard SQL — Engines akzeptieren allerhand, was der Standard nicht vorsieht. Es kann auch eine wirklich engine-spezifische Erweiterung sein, die der Parser nicht abbildet; dann ist die Abfrage in Ordnung und das Werkzeug schlicht nicht die Autorität dafür. Deine Datenbank ist es.
Soll ich Schlüsselwörter großschreiben?
Für die Engine macht es keinen Unterschied. Die Konvention existiert, weil sie die Sprache auf einen Blick von deinen Daten trennt: In SELECT name FROM users sind die großgeschriebenen Wörter SQL und die kleingeschriebenen deine. Die meisten Teams folgen ihr, und die nützliche Regel lautet, sich dem anzupassen, was in deiner Codebasis schon steht, statt eine Meinung zu haben.
Kann es eine Stored Procedure oder ein großes Migrationsskript formatieren?
Es kommt mit mehreren Anweisungen zurecht und trennt sie für dich. Prozedurale Erweiterungen — PL/pgSQL, MySQL-Routinen, T-SQL-Kontrollfluss — sind eine eigene Sprache auf SQL obendrauf, und die Unterstützung schwankt je nach Dialekt. Kommt ein Prozedurrumpf verstümmelt zurück, hast du diese Grenze erreicht, und die Antwort ist, die Abfragen darin zu formatieren statt der ganzen Routine.