SQL Diff: sammenlign to SQL-filer online
Indsæt, formatér og sammenlign to SQL-forespørgsler eller skemafiler side om side. Virker for PostgreSQL, MySQL, SQL Server, SQLite og Oracle.
Hvad er SQL-diff-værktøjet?
Et gratis browserbaseret værktøj til at sammenligne to SQL-filer. Indsæt en gammel CREATE TABLE til venstre, den nye til højre, og ændringerne lyser op tegn for tegn. Samme flow til to versioner af en analyseforespørgsel, en sætning udsendt af et ORM eller udskriften fra et pg_dump. Intet forlader din maskine.
Diffen arbejder på tekstniveau. Den parser ikke SQL til en AST og forstår ikke semantisk ækvivalens: SELECT a, b og SELECT b, a ser forskellige ud for diffen, selvom begge returnerer de samme rækker i en anden rækkefølge. Til 95% af kodegennemgangsopgaver (skemamigreringer, query-refaktoreringer, sammenligning af ORM-output) er tekst-diff lige det, du faktisk vil have, fordi rækkefølgen af kolonner og klausuler er en del af, hvordan teamet læser ændringen.
Hvis du nogensinde har prøvet at finde den ene nye WHERE-klausul i en 400-linjers analyseforespørgsel, der begyndte at returnere et andet rækkeantal, så er dette værktøjet, der får dig derhen på sekunder. Til ikke-SQL-prosa er vores tekst-diff-værktøj det rette valg. Til ORM-resultatpayloads i JSON håndterer JSON-diff objektomrokering pænere. Til ældre DDL-eksporter skrevet som XML-metadata passer XML-diff bedre.
Hvordan diffen rent faktisk fungerer
Under motorhjelmen kører diffen på tegnniveau, og derefter rykker en semantisk passage markeringerne, så de lander på identifikatorer, nøgleord og klausulgrænser i stedet for tilfældig tegnsætning. Indsættelser vises grønne til højre, sletninger røde til venstre. Hver rude har en Format-knap, der ombryder SQL med konsistent indrykning og én sætning pr. linje, hvilket fjerner det meste formaterings-støj før sammenligningen.
SQL er en familie af dialekter, ikke et enkelt sprog. ISO/IEC 9075-standarden definerer en kernegrammatik, men hver database udvider den: PostgreSQL har dollar-citerede strenge og RETURNING, MySQL har backtick-identifikatorer og ON DUPLICATE KEY UPDATE, SQL Server bruger TOP og identifikatorer i firkantede parenteser, SQLite tolererer næsten alt, og Oracle har ROWNUM og CONNECT BY. At diffe på tværs af dialekter går fint; værktøjet vil ikke advare om, at et udsnit er ugyldigt i en af dem.
Det andet at vide: at sammenligne en forespørgsels tekst er ikke det samme som at sammenligne dens planer. To sætninger med identisk tekst kan producere meget forskellige planer på forskellige statistikker, og to kosmetisk forskellige sætninger kan producere identiske planer. Til planjamenligning er de rigtige værktøjer EXPLAIN ANALYZE i psql eller pendanten i din databaseklient (DataGrip, DBeaver, SSMS). Til tekstrefaktoreringsgennemgang er diffen det, du vil have. Baggrundslæsning om selve sproget på Wikipedia.
Sådan sammenligner du SQL i tre trin
To tekstruder, én diff. Ingen tilmelding, ingen upload, ingen server-rundtur.
- 1
Indsæt eller upload din SQL
Indsæt den gamle SQL til venstre, den nye til højre. Eller klik på Upload på en af siderne for at indlæse en .sql-, .ddl- eller .psql-fil direkte. Sample-knappen fylder begge ruder med et lille orders-skemaeksempel, hvis du vil se værktøjet i aktion først.
- 2
Formatér begge sider for en fair sammenligning
Klik på Format på hver rude for at ombryde SQL med konsistent indrykning, én sætning pr. linje og nøgleord med store bogstaver. Det dræber støjen fra en DataGrip-formateret forespørgsel på den ene side og en håndskrevet på den anden, så diffen fremhæver rigtige skema- og klausulændringer i stedet for whitespace- og storbogstavsforskelle.
- 3
Læs diffen
Sletninger vises med rød fremhævning til venstre, indsættelser med grøn fremhævning til højre. Rul i den ene side, og den anden følger med. Ændringstællerne i hver header fortæller, hvor mange separate redigeringer diffen fandt på tværs af kolonner, joins, prædikater og DDL-elementer.
Hvornår SQL-diff er det rette værktøj
Gennemgå en skemamigrering før den anvendes
En migrerings-PR tilføjer tre kolonner og justerer to indekser. Indsæt den tidligere CREATE TABLE mod den nye, og tilføjelserne stikker ud: en kolonne currency CHAR(3) NOT NULL blev tilføjet uden DEFAULT, hvilket vil fejle på enhver eksisterende række. At fange det, før migreringen kører mod prod, frem for efter at deploy-alarmen går klokken 2 om natten, er hele pointen med dette flow. Samme værdi for ALTER TABLE-sætninger, hvor en kolonnetype indsnævres fra VARCHAR(255) til VARCHAR(50).
Diff to versioner af en analyseforespørgsel
En rapportforespørgsel, der i går returnerede 12.400 rækker, returnerer i dag 8.900. Diff gårsdagens gemte forespørgsel mod dagens, og den skyldige ændring kommer frem: en LEFT JOIN blev stille til en INNER JOIN, eller en WHERE status <> 'cancelled' blev tilføjet af en, der prøvede at rydde op i dashboardet. Tekst-diffen lander dig på linjen på sekunder, hvor det at læse begge forespørgsler side om side i Slack ville tage ti minutter.
Sammenligne ORM-genereret SQL mellem app-versioner
Efter en Hibernate- eller SQLAlchemy-opgradering er forespørgsler, der var tre joins, nu fire med ekstra subqueries, eller parameterbinding er gået fra ? til $1-pladsholdere. Indfang SQL fra din query-log på hver app-version (psql log_statement = all, MySQL slow log eller dit APM-værktøj) og diff dem. Aliasnavnene vil være støjende (t1, t2, generatedAlias0), men den faktiske strukturelle ændring er som regel det eneste, diffen fremhæver som en rigtig redigering.
Validere at en DDL-refaktorering bevarer hensigten
Du omdøbte user_orders til orders og opdelte en JSON-blob-kolonne i normaliserede tabeller. Indsæt pg_dump --schema-only-output før og efter refaktoreringen; diffen gør det åbenlyst, om du bevarede hver constraint, hvert indeks og hver default. Fælden at holde øje med er et NOT NULL, der stille forsvandt under omdøbningen, eller et UNIQUE-constraint, der faldt ud, fordi ingen tilføjede det igen på den nye tabel.
Tjekke at staging-skema matcher prod
Kør pg_dump --schema-only --no-owner mod staging og prod, og diff de to. Forskellene burde være præcis de migreringer, der er i kø til næste deploy. Alt andet, et ekstra indeks, en anden kolonnetype, en glemt testtabel, er et tegn på skema-drift, der vil bide under selve deployen. Samme tilgang med mysqldump --no-data for MySQL og SCRIPT TO for SQL Server, eller DataGrips skemaeksport på tværs af enhver database.
Gennemgå dialektportering (Postgres til MySQL)
At portere en forespørgsel fra PostgreSQL til MySQL eller omvendt betyder at holde styr på, hvilke funktioner, typer og klausuler der skal ændres: SERIAL versus AUTO_INCREMENT, NOW() versus CURRENT_TIMESTAMP, RETURNING versus LAST_INSERT_ID(). Diff originalen mod den porterede version, og alle dialektsubstitutioner kommer frem. Diffen vil ikke validere SQL i måldialekten, så kør den alligevel gennem psql eller mysql for at bekræfte, men linje-for-linje-visningen fortæller, hvilke beslutninger der skal tjekkes en ekstra gang.
SQL hurtig reference
Et kort snydeark over de dialekt- og parsing-edge cases, denne diff oftest bringer i overfladen. Forankret i ISO SQL-standarden og de store leverandørers dokumentation.
| Topic | What this tool does |
|---|
| Dialekt-drift | PostgreSQL, MySQL, SQL Server, SQLite og Oracle udvider hver især ISO SQL-standarden med egen syntaks. SERIAL, AUTO_INCREMENT, IDENTITY og GENERATED ALWAYS AS IDENTITY er fire måder at skrive den samme idé på. |
|---|
| Identifikator-foldning af store/små | PostgreSQL folder uciterede identifikatorer til små bogstaver, så Users og users er den samme tabel. MySQL afhænger af lower_case_table_names og det underliggende filsystem. SQL Server er som standard størrelsesufølsom, men respekterer collationen. Citér identifikatorer med "Users" (standard), backticks (MySQL) eller firkantede parenteser (SQL Server) for at bevare store/små bogstaver. |
|---|
| Nøgleordsstørrelse | SQL-nøgleord er størrelsesufølsomme overalt, så SELECT og select er identiske for parseren. Konventionen er store bogstaver til nøgleord og små til identifikatorer; de fleste stilguider og ISO-specifikationen følger den. Blandet størrelse er gyldig og kører, men værktøjer som sqlfluff og sqlfmt normaliserer det. |
|---|
| Kommentarstilarter | To former: -- linjekommentar (slutter ved linjeskift) og /* blokkommentar */ (ingen indlejring i standard-SQL, selvom nogle dialekter tillader det). MySQL understøtter også # til linjekommentarer som udvidelse. Diffen behandler kommentarer som tekst og viser kommentarredigeringer som enhver anden ændring. |
|---|
| Sætningsadskillere | Semikolon (;) afslutter en sætning i standard-SQL. De fleste klienter kræver det mellem sætninger i et script. Nogle klienter (SSMS) bruger i stedet GO som batchadskiller, hvilket ikke er en del af SQL-grammatikken; det er et klientdirektiv. |
|---|
| Dollar-citerede strenge (PostgreSQL) | PostgreSQL understøtter $tag$ ... $tag$ til strenglitteraler, så du ikke skal escape-e enkelte anførselstegn indeni, særligt nyttigt til funktionskroppe. $$ SELECT 'hello' $$ er gyldigt og almindeligt i CREATE FUNCTION-blokke. Andre dialekter parser ikke denne syntaks. |
|---|
| Parameterbindings-pladsholdere | Ingen standard. PostgreSQL og ORM'er, der retter sig mod det, bruger $1, $2. JDBC, MySQL og ODBC bruger ?. Navngivne pladsholdere :name er almindelige i Oracle og i mange ORM-strengskabeloner. ORM-genereret SQL adskiller sig ofte mellem versioner kun i pladsholderstil; formatér begge sider før diff. |
|---|
| Encoding | UTF-8 er den universelle standard for SQL-filer i 2026. Ældre Windows-stammede scripts kan stadig være gemt som UTF-16 LE med BOM, hvilket dukker op som et spøgelses-tegn på linje 1 i en tekst-diff. Hvis to filer ser identiske ud, men diffen flagger en enkelt-tegn-ændring i begyndelsen, så mistænk BOM'en og gem igen med eksplicit UTF-8. |
|---|
SQL-diff: ofte stillede spørgsmål
Hvordan adskiller dette sig fra at køre EXPLAIN ANALYZE på begge forespørgsler?
Andet lag af stakken. EXPLAIN ANALYZE viser dig forespørgslens plan, det optimeringsmodulet besluttede at gøre givet de statistikker, det har. Dette værktøj differ forespørgslens tekst, det der ændrede sig i dit repo. Du vil typisk have begge: denne diff for at opdage refaktoreringen (en jointype ændrede sig, et prædikat flyttede sig), så EXPLAIN ANALYZE i psql eller din klient for at bekræfte, at optimeringsmodulet faktisk valgte en fornuftig plan til den nye form. De to supplerer hinanden, de erstatter ikke.
Er diffen dialektbevidst (PostgreSQL vs MySQL vs SQL Server)?
Nej. Diffen behandler input som tekst, så den parser ikke PostgreSQL, MySQL, SQL Server, SQLite eller Oracle forskelligt og flagger ikke dialektinkompatibel syntaks. Det er bevidst: det betyder, at du kan diffe på tværs af dialekter, hvilket er præcis, hvad du vil, når du porterer en forespørgsel. Skal du have dialektbevidst linting, så kør SQL gennem sqlfluff eller din databases parser separat. Til gennemgangsbrugen ("hvad ændrede sig i denne forespørgsel") er tekstniveau den rette granularitet.
Formaterer værktøjet SQL for mig?
Ja, Format-knappen på hver rude ombryder SQL med konsistent indrykning, nøgleord med store bogstaver og én sætning pr. linje. Det er en grundlæggende formatter, ikke en erstatning for sqlfmt eller sqlfluff: den omskriver ikke implicitte joins til eksplicitte, og den håndhæver ikke en bestemt dialekts stilguide. Pointen er at fjerne formateringsstøj før diffen, så en DataGrip-formateret forespørgsel på den ene side og en håndskrevet på den anden sammenlignes rent.
Normaliserer den nøgleordsstørrelse (SELECT vs select)?
Format-knappen sætter nøgleord med store bogstaver, hvilket er konventionen i de fleste stilguider og i ISO SQL-standarden. Hvis du ikke klikker på Format, dukker blandet store/små op som diff, fordi den underliggende motor er tegnbaseret. SQL-nøgleord er størrelsesufølsomme i alle databaser, så select og SELECT kører identisk. Identifikatorstørrelse er et andet spørgsmål og varierer mellem databaser; se hurtigreferencen nedenfor for, hvordan Postgres, MySQL og SQL Server adskiller sig.
Hvordan håndterer jeg ORM-genererede aliasser som t1, t2, generatedAlias0?
ORM-output er støjende per design: Hibernate genererer generatedAlias0, generatedAlias1, og SQLAlchemy bruger anon_1, anon_2. Hvis to ORM-versioner tildeler de samme aliasser i en anden rækkefølge, vil tekst-diffen fremhæve hvert alias-bytte som en ændring, selv om forespørgslen er strukturelt identisk. Den praktiske løsning er at formatere begge sider, ignorere alias-kun-forskelle (typisk åbenlyse som parrede røde og grønne blokke på samme linje) og fokusere på de faktiske strukturelle redigeringer: et nyt join, en anden WHERE-klausul, en fjernet kolonne.
Er der størrelsesgrænser på den SQL, jeg indsætter?
Bløde grænser, ikke hårde. Diffen kører i din browser, så loftet er din browsers hukommelse, og hvor længe du er villig til at vente. En 5.000-linjers pg_dump-output diffes i et godt stykke under et sekund på en moderne laptop. En dump på 200.000 linjer kan tage flere sekunder og ramme hukommelsesgrænser på svagere enheder. For så store databasedumps er det rette flow at diffe kun skema først (pg_dump --schema-only) og derefter dykke ned i specifikke tabeller, hvis du har brug for sammenligning på dataniveau.
Privatliv og hvordan det virker
Din SQL forlader aldrig din browser. Formatteren og diffen kører begge på din maskine, lokalt. Ingen analytics på dit input, ingen logs, ingen "hjælpsom" cloud-rundtur, hvilket betyder noget, når den SQL, du indsætter, indeholder rigtige tabelnavne, rigtige kolonnenavne eller rigtige produktionsdata i en eksempelrække. Sproget er dokumenteret i ISO/IEC 9075, og dialektreferencerne er PostgreSQL, MySQL, SQL Server og SQLite.