SQL Diff: Zwei SQL-Dateien online vergleichen
Fügen Sie zwei SQL-Abfragen oder Schemadateien ein, formatieren Sie sie und vergleichen Sie sie nebeneinander. Funktioniert für PostgreSQL, MySQL, SQL Server, SQLite und Oracle.
Was ist das SQL-Diff-Tool?
Ein kostenloses Tool im Browser zum Vergleichen zweier SQL-Dateien. Fügen Sie ein altes CREATE TABLE links ein, das neue rechts, und die Änderungen leuchten Zeichen für Zeichen auf. Gleicher Ablauf für zwei Versionen einer Analyse-Abfrage, ein vom ORM erzeugtes Statement oder eine pg_dump-Ausgabe. Nichts verlässt Ihren Rechner.
Der Diff arbeitet auf Textebene. Er parst das SQL nicht in einen AST und versteht keine semantische Äquivalenz: SELECT a, b und SELECT b, a wirken für den Diff verschieden, auch wenn beide dieselben Zeilen in anderer Reihenfolge zurückgeben. Für 95 % der Code-Review-Aufgaben (Schemamigrationen, Query-Refactorings, Vergleich von ORM-Output) ist Text-Diff genau das, was man tatsächlich will, denn die Reihenfolge von Spalten und Klauseln gehört dazu, wie das Team die Änderung liest.
Wenn Sie schon mal versucht haben, in einer 400-zeiligen Analyse-Abfrage die eine neue WHERE-Klausel zu finden, die plötzlich eine andere Zeilenzahl liefert, ist dies das Tool, das Sie in Sekunden dorthin bringt. Für Nicht-SQL-Text ist unser Text-Diff-Tool die richtige Wahl. Für ORM-Result-Payloads in JSON behandelt JSON-Diff Objekt-Umsortierungen sauberer. Für alte DDL-Exporte als XML-Metadaten passt XML-Diff besser.
Wie der Diff tatsächlich arbeitet
Unter der Haube läuft der Diff auf Zeichenebene, dann verschiebt ein semantischer Pass die Highlights, sodass sie auf Bezeichner, Schlüsselwörter und Klauselgrenzen fallen statt auf zufällige Satzzeichen. Einfügungen erscheinen rechts in Grün, Löschungen links in Rot. Jeder Bereich hat eine Format-Schaltfläche, die das SQL mit konsistenter Einrückung und einem Statement pro Zeile umbricht, was den größten Teil des Formatierungsrauschens vor dem Vergleich beseitigt.
SQL ist eine Familie von Dialekten, keine einzelne Sprache. Der ISO/IEC 9075-Standard definiert eine Kerngrammatik, aber jede Datenbank erweitert sie: PostgreSQL hat Dollar-Quoting-Strings und RETURNING, MySQL hat Backtick-Bezeichner und ON DUPLICATE KEY UPDATE, SQL Server nutzt TOP und Bezeichner in eckigen Klammern, SQLite toleriert fast alles, und Oracle hat ROWNUM und CONNECT BY. Diff über Dialekte hinweg ist in Ordnung; das Tool warnt Sie nicht, dass ein Snippet in einem davon ungültig ist.
Außerdem wichtig zu wissen: der Vergleich von Abfrage-text ist nicht dasselbe wie der Vergleich von Abfrage-plänen. Zwei Statements mit identischem Text können bei unterschiedlichen Statistiken sehr unterschiedliche Pläne erzeugen, und zwei kosmetisch verschiedene Statements können denselben Plan erzeugen. Für den Plan-Vergleich sind EXPLAIN ANALYZE in psql oder das Äquivalent in Ihrem Datenbank-Client (DataGrip, DBeaver, SSMS) die richtigen Werkzeuge. Für Text-Refactoring-Reviews ist der Diff das, was Sie wollen. Hintergrundlektüre zur Sprache selbst auf Wikipedia.
SQL in drei Schritten vergleichen
Zwei Textbereiche, ein Diff. Keine Anmeldung, kein Upload, kein Server-Roundtrip.
- 1
SQL einfügen oder hochladen
Fügen Sie das alte SQL links ein, das neue rechts. Oder klicken Sie auf Hochladen auf einer der Seiten, um eine .sql-, .ddl- oder .psql-Datei direkt zu laden. Die Beispiel-Schaltfläche füllt beide Bereiche mit einem kleinen orders-Schema, falls Sie das Tool zuerst in Aktion sehen möchten.
- 2
Beide Seiten formatieren für einen fairen Vergleich
Klicken Sie auf Format in jedem Bereich, um das SQL mit konsistenter Einrückung, einem Statement pro Zeile und Schlüsselwörtern in Großbuchstaben umzubrechen. Das beseitigt den Lärm einer von DataGrip formatierten Abfrage auf einer Seite und einer handgetippten auf der anderen, sodass der Diff echte Schema- und Klauseländerungen hervorhebt statt Whitespace- und Casing-Unterschiede.
- 3
Den Diff lesen
Löschungen erscheinen mit roter Hervorhebung links, Einfügungen mit grüner Hervorhebung rechts. Scrollen Sie eine Seite, folgt die andere. Die Änderungszähler in jeder Kopfzeile sagen Ihnen, wie viele unterschiedliche Edits der Diff in Spalten, Joins, Prädikaten und DDL-Elementen gefunden hat.
Wann SQL-Diff das richtige Werkzeug ist
Schemamigration vor dem Anwenden prüfen
Ein Migrations-PR fügt drei Spalten hinzu und justiert zwei Indizes. Fügen Sie das vorherige CREATE TABLE gegen das neue ein, und die Ergänzungen stechen heraus: eine Spalte currency CHAR(3) NOT NULL wurde ohne DEFAULT hinzugefügt, was bei jeder bestehenden Zeile fehlschlägt. Das vor dem Lauf der Migration in Produktion zu erwischen, statt nach dem Deploy-Alarm um 2 Uhr morgens, ist der gesamte Sinn dieses Workflows. Gleicher Wert für ALTER TABLE-Statements, in denen sich ein Spaltentyp von VARCHAR(255) auf VARCHAR(50) verengt.
Diff zweier Versionen einer Analyse-Abfrage
Eine Reporting-Abfrage, die gestern 12.400 Zeilen lieferte, liefert heute 8.900. Diff von gestern gespeicherter Abfrage gegen die heutige, und die schuldige Änderung kommt hoch: ein LEFT JOIN wurde stillschweigend zu einem INNER JOIN, oder ein WHERE status <> 'cancelled' wurde von jemandem hinzugefügt, der das Dashboard aufräumen wollte. Der Text-Diff bringt Sie in Sekunden auf die Zeile, während das Lesen beider Abfragen nebeneinander in Slack zehn Minuten dauern würde.
ORM-generiertes SQL zwischen App-Versionen vergleichen
Nach einem Hibernate- oder SQLAlchemy-Upgrade sind aus Abfragen mit drei Joins vier mit zusätzlichen Subqueries geworden, oder das Parameter-Binding wechselt von ? zu $1-Platzhaltern. Erfassen Sie das SQL aus dem Query-Log jeder App-Version (psql log_statement = all, MySQL Slow Log oder Ihr APM-Tool) und differieren Sie sie. Die Aliasnamen werden laut sein (t1, t2, generatedAlias0), aber die tatsächliche strukturelle Änderung ist meist das Einzige, was der Diff als echten Edit hervorhebt.
Validieren, dass ein DDL-Refactoring die Absicht erhält
Sie haben user_orders in orders umbenannt und eine JSON-Blob-Spalte in normalisierte Tabellen aufgeteilt. Fügen Sie die pg_dump --schema-only-Ausgabe vor und nach dem Refactoring ein; der Diff macht klar, ob Sie jeden Constraint, Index und Default erhalten haben. Die Falle, auf die zu achten ist, ist ein NOT NULL, das beim Umbenennen leise verschwand, oder ein UNIQUE-Constraint, der weggefallen ist, weil ihn niemand auf der neuen Tabelle wieder hinzugefügt hat.
Prüfen, ob das Staging-Schema mit Prod übereinstimmt
Führen Sie pg_dump --schema-only --no-owner gegen Staging und Prod aus und differieren Sie die beiden. Die Unterschiede sollten genau die für das nächste Deployment vorgesehenen Migrationen sein. Alles andere, ein zusätzlicher Index, ein anderer Spaltentyp, eine vergessene Test-Tabelle, ist ein Zeichen für Schema-Drift, der beim eigentlichen Deployment beißt. Gleicher Ansatz mit mysqldump --no-data für MySQL und SCRIPT TO für SQL Server, oder DataGrips Schema-Export über jede Datenbank.
Dialekt-Portierung prüfen (Postgres zu MySQL)
Eine Abfrage von PostgreSQL zu MySQL oder umgekehrt zu portieren bedeutet, im Blick zu behalten, welche Funktionen, Typen und Klauseln sich ändern müssen: SERIAL versus AUTO_INCREMENT, NOW() versus CURRENT_TIMESTAMP, RETURNING versus LAST_INSERT_ID(). Differieren Sie das Original gegen die portierte Version, und alle Dialekt-Substitutionen kommen heraus. Der Diff validiert das SQL nicht im Zieldialekt, lassen Sie es zur Bestätigung trotzdem durch psql oder mysql laufen, aber die zeilenweise Sicht sagt Ihnen, welche Entscheidungen doppelt zu prüfen sind.
SQL-Kurzreferenz
Ein kurzer Spickzettel zu Dialekt- und Parsing-Edge-Cases, die dieser Diff am häufigsten an die Oberfläche bringt. Geerdet im ISO-SQL-Standard und den großen Hersteller-Dokumentationen.
| Topic | What this tool does |
|---|
| Dialekt-Drift | PostgreSQL, MySQL, SQL Server, SQLite und Oracle erweitern jeweils den ISO-SQL-Standard um eigene Syntax. SERIAL, AUTO_INCREMENT, IDENTITY und GENERATED ALWAYS AS IDENTITY sind vier Schreibweisen derselben Idee. |
|---|
| Bezeichner-Case-Folding | PostgreSQL faltet ungeschriebene Bezeichner in Kleinbuchstaben, also sind Users und users dieselbe Tabelle. MySQL hängt von lower_case_table_names und dem zugrundeliegenden Dateisystem ab. SQL Server ist standardmäßig case-insensitive, respektiert aber die Collation. Setzen Sie Bezeichner mit "Users" (Standard), Backticks (MySQL) oder eckigen Klammern (SQL Server) in Anführungszeichen, um den Case zu erhalten. |
|---|
| Schlüsselwort-Schreibweise | SQL-Schlüsselwörter sind überall case-insensitive, also sind SELECT und select für den Parser identisch. Konvention ist Großbuchstaben für Schlüsselwörter und Kleinbuchstaben für Bezeichner; die meisten Styleguides und die ISO-Spezifikation folgen dem. Gemischte Schreibweise ist gültig und führt aus, aber Tools wie sqlfluff und sqlfmt normalisieren sie. |
|---|
| Kommentarstile | Zwei Formen: -- Zeilenkommentar (endet am Zeilenende) und /* Blockkommentar */ (kein Verschachteln in Standard-SQL, manche Dialekte erlauben es). MySQL unterstützt zusätzlich # für Zeilenkommentare als Erweiterung. Der Diff behandelt Kommentare als Text und zeigt Kommentar-Edits wie jede andere Änderung. |
|---|
| Statement-Trennzeichen | Semikolon (;) beendet ein Statement in Standard-SQL. Die meisten Clients verlangen es zwischen Statements in einem Skript. Manche Clients (SSMS) verwenden stattdessen GO als Batch-Trenner, was nicht Teil der SQL-Grammatik ist; es ist eine Client-Direktive. |
|---|
| Dollar-Quoting-Strings (PostgreSQL) | PostgreSQL unterstützt $tag$ ... $tag$ für String-Literale, sodass Sie einfache Anführungszeichen darin nicht escapen müssen, besonders nützlich für Funktionskörper. $$ SELECT 'hello' $$ ist gültig und üblich in CREATE FUNCTION-Blöcken. Andere Dialekte parsen diese Syntax nicht. |
|---|
| Parameter-Binding-Platzhalter | Kein Standard. PostgreSQL und ORMs, die darauf zielen, nutzen $1, $2. JDBC, MySQL und ODBC nutzen ?. Benannte Platzhalter :name sind in Oracle und vielen ORM-String-Templates üblich. ORM-generiertes SQL über Versionen hinweg unterscheidet sich oft nur im Platzhalter-Stil; formatieren Sie beide Seiten vor dem Diff. |
|---|
| Encoding | UTF-8 ist 2026 der universelle Default für SQL-Dateien. Ältere Skripte aus Windows-Quellen können noch als UTF-16 LE mit BOM gespeichert sein, was als Geisterzeichen in Zeile 1 eines Text-Diffs auftaucht. Wenn zwei Dateien identisch aussehen, der Diff aber eine Ein-Zeichen-Änderung am Anfang meldet, vermuten Sie das BOM und speichern Sie mit explizitem UTF-8 neu. |
|---|
SQL-Diff: häufig gestellte Fragen
Wie unterscheidet sich das davon, EXPLAIN ANALYZE auf beiden Abfragen laufen zu lassen?
Andere Schicht des Stacks. EXPLAIN ANALYZE zeigt Ihnen den Plan der Abfrage, was der Optimierer angesichts seiner Statistiken zu tun beschlossen hat. Dieses Tool differiert den Text der Abfrage, das, was sich in Ihrem Repo geändert hat. In der Regel will man beides: diesen Diff, um das Refactoring zu erkennen (ein Join-Typ hat sich geändert, ein Prädikat ist umgezogen), dann EXPLAIN ANALYZE in psql oder Ihrem Client, um zu bestätigen, dass der Optimierer für die neue Form tatsächlich einen sinnvollen Plan gewählt hat. Beide ergänzen sich, sie ersetzen sich nicht.
Ist der Diff dialektbewusst (PostgreSQL vs MySQL vs SQL Server)?
Nein. Der Diff behandelt die Eingabe als Text, parst PostgreSQL, MySQL, SQL Server, SQLite oder Oracle also nicht unterschiedlich und markiert keine dialekt-inkompatible Syntax. Das ist Absicht: es bedeutet, dass Sie über Dialekte hinweg differieren können, was beim Portieren einer Abfrage genau das ist, was Sie wollen. Wenn Sie dialektbewusstes Linting brauchen, jagen Sie das SQL separat durch sqlfluff oder den Parser Ihrer Datenbank. Für den Review-Anwendungsfall ("was hat sich in dieser Abfrage geändert") ist die Textebene die richtige Granularität.
Formatiert das Tool SQL für mich?
Ja, die Format-Schaltfläche in jedem Bereich bricht das SQL mit konsistenter Einrückung, Schlüsselwörtern in Großbuchstaben und einem Statement pro Zeile um. Es ist ein einfacher Formatter, kein Ersatz für sqlfmt oder sqlfluff: er schreibt implizite Joins nicht in explizite um und erzwingt keinen Styleguide eines bestimmten Dialekts. Der Punkt ist, das Formatierungsrauschen vor dem Diff zu beseitigen, sodass eine von DataGrip formatierte Abfrage auf einer Seite und eine handgetippte auf der anderen sauber verglichen werden.
Normalisiert es die Schreibweise von Schlüsselwörtern (SELECT vs select)?
Die Format-Schaltfläche schreibt Schlüsselwörter groß, was die Konvention der meisten Styleguides und des ISO-SQL-Standards ist. Wenn Sie nicht auf Format klicken, taucht gemischte Schreibweise als Diff auf, weil die zugrundeliegende Engine zeichenbasiert ist. SQL-Schlüsselwörter sind in jeder Datenbank case-insensitive, also führen select und SELECT identisch aus. Bezeichner-Casing ist eine andere Frage und variiert nach Datenbank; die Kurzreferenz unten zeigt, wie sich Postgres, MySQL und SQL Server unterscheiden.
Wie gehe ich mit ORM-erzeugten Aliasen wie t1, t2, generatedAlias0 um?
ORM-Output ist von Natur aus laut: Hibernate erzeugt generatedAlias0, generatedAlias1, und SQLAlchemy nutzt anon_1, anon_2. Wenn zwei ORM-Versionen dieselben Aliase in anderer Reihenfolge zuweisen, hebt der Text-Diff jeden Alias-Tausch als Änderung hervor, auch wenn die Abfrage strukturell identisch ist. Die praktische Lösung ist, beide Seiten zu formatieren, reine Alias-Unterschiede zu ignorieren (sie sind meist offensichtlich als gepaarte rote und grüne Spannen auf derselben Zeile) und sich auf die echten strukturellen Edits zu konzentrieren: ein neuer Join, eine andere WHERE-Klausel, eine entfernte Spalte.
Gibt es Größenlimits für das eingefügte SQL?
Weiche Limits, keine harten. Der Diff läuft im Browser, die Obergrenze ist also der Speicher Ihres Browsers und wie lange Sie zu warten bereit sind. Eine 5.000-zeilige pg_dump-Ausgabe wird auf einem modernen Laptop in deutlich unter einer Sekunde differiert. Ein 200.000-zeiliger Dump kann mehrere Sekunden dauern und auf schwächeren Geräten an Speichergrenzen stoßen. Für so große Datenbank-Dumps ist der richtige Ablauf, zuerst nur das Schema zu differieren (pg_dump --schema-only) und dann in spezifische Tabellen zu bohren, falls ein Vergleich auf Datenebene nötig ist.
Datenschutz und Funktionsweise
Ihr SQL verlässt nie Ihren Browser. Formatter und Diff laufen beide auf Ihrer Maschine, lokal. Keine Analytik auf Ihre Eingabe, keine Logs, kein "hilfreicher" Cloud-Roundtrip, was zählt, wenn das eingefügte SQL echte Tabellennamen, echte Spaltennamen oder echte Produktionsdaten in einer Beispielzeile enthält. Die Sprache ist in ISO/IEC 9075 dokumentiert, und die Dialekt-Referenzen sind PostgreSQL, MySQL, SQL Server und SQLite.