SQL Diff: sammenlign to SQL-filer på nett
Lim inn, formater og sammenlign to SQL-spørringer eller skjemafiler side ved side. Fungerer for PostgreSQL, MySQL, SQL Server, SQLite og Oracle.
Hva er SQL-diff-verktøyet?
Et gratis nettleserverktøy for å sammenligne to SQL-filer. Lim inn en gammel CREATE TABLE til venstre, den nye til høyre, og endringene lyser opp tegn for tegn. Samme flyt for to versjoner av en analysespørring, en setning generert av en ORM, eller utskriften fra et pg_dump. Ingenting forlater maskinen din.
Diffen jobber på tekstnivå. Den parser ikke SQL til en AST og forstår ikke semantisk ekvivalens: SELECT a, b og SELECT b, a ser ulike ut for diffen, selv om begge returnerer de samme radene i en annen rekkefølge. For 95 % av kodegjennomgangsoppgaver (skjemamigrasjoner, spørringsrefaktoreringer, sammenligning av ORM-utskrift) er tekst-diff akkurat det du faktisk vil ha, fordi rekkefølgen på kolonner og setninger er en del av hvordan teamet leser endringen.
Hvis du noen gang har prøvd å finne den ene nye WHERE-setningen i en 400-linjers analysespørring som begynte å returnere et annet radantall, er dette verktøyet som tar deg dit på sekunder. For ikke-SQL-prosa er tekst-diff-verktøyet vårt riktig valg. For ORM-resultatpayloader i JSON håndterer JSON-diff omrokering av objekter penere. For eldre DDL-eksporter skrevet som XML-metadata passer XML-diff bedre.
Hvordan diffen faktisk fungerer
Under panseret kjører diffen på tegnnivå, og deretter forskyver en semantisk passering uthevingene slik at de lander på identifikatorer, nøkkelord og setningsgrenser i stedet for tilfeldig tegnsetting. Innsettinger vises i grønt til høyre, slettinger i rødt til venstre. Hver rute har en Format-knapp som ombryter SQL med konsistent innrykk og én setning per linje, noe som dreper det meste av formateringsstøy før sammenligningen.
SQL er en familie av dialekter, ikke ett enkelt språk. ISO/IEC 9075-standarden definerer en kjernegrammatikk, men hver database utvider den: PostgreSQL har dollar-siterte strenger og RETURNING, MySQL har backtick-identifikatorer og ON DUPLICATE KEY UPDATE, SQL Server bruker TOP og identifikatorer i hakeparenteser, SQLite tolererer nesten hva som helst, og Oracle har ROWNUM og CONNECT BY. Å diffe på tvers av dialekter går fint; verktøyet vil ikke advare om at en bit er ugyldig i en av dem.
Det andre å vite: å sammenligne teksten til en spørring er ikke det samme som å sammenligne planene. To setninger med identisk tekst kan produsere svært ulike planer på ulik statistikk, og to kosmetisk ulike setninger kan produsere identiske planer. For planjevenligning er de riktige verktøyene EXPLAIN ANALYZE i psql eller motstykket i databaseklienten din (DataGrip, DBeaver, SSMS). Til tekst-refaktoreringsgjennomgang er diffen det du vil ha. Bakgrunnslesing om språket selv på Wikipedia.
Slik sammenligner du SQL i tre steg
To tekstruter, én diff. Ingen registrering, ingen opplasting, ingen server-rundtur.
- 1
Lim inn eller last opp SQL-en din
Lim inn den gamle SQL til venstre, den nye til høyre. Eller klikk Last opp på en av sidene for å laste inn en .sql-, .ddl- eller .psql-fil direkte. Sample-knappen fyller begge ruter med et lite orders-skjemaeksempel hvis du vil se verktøyet i aksjon først.
- 2
Formater begge sider for en rettferdig sammenligning
Klikk Format på hver rute for å ombryte SQL med konsistent innrykk, én setning per linje og nøkkelord i store bokstaver. Det dreper støyen fra en DataGrip-formatert spørring på den ene siden og en håndskrevet på den andre, så diffen fremhever ekte skjema- og setningsendringer i stedet for whitespace- og bokstavstørrelsesforskjeller.
- 3
Les diffen
Slettinger vises med rød utheving til venstre, innsettinger med grønn utheving til høyre. Skroll på den ene siden, og den andre følger. Endringstellerne i hver header forteller hvor mange separate redigeringer diffen fant på tvers av kolonner, joins, predikater og DDL-elementer.
Når SQL-diff er det riktige verktøyet
Gjennomgå en skjemamigrasjon før den brukes
En migrasjons-PR legger til tre kolonner og justerer to indekser. Lim inn den forrige CREATE TABLE mot den nye, og tilleggene stikker ut: en kolonne currency CHAR(3) NOT NULL ble lagt til uten DEFAULT, noe som vil feile på enhver eksisterende rad. Å fange det før migrasjonen kjører mot prod, i stedet for etter at deploy-alarmen går klokken 2 om natten, er hele poenget med denne flyten. Samme verdi for ALTER TABLE-setninger der en kolonnetype smalner fra VARCHAR(255) til VARCHAR(50).
Diff to versjoner av en analysespørring
En rapportspørring som i går returnerte 12 400 rader returnerer i dag 8 900. Diff i går lagrede spørring mot dagens, og den skyldige endringen kommer frem: en LEFT JOIN ble stille til en INNER JOIN, eller en WHERE status <> 'cancelled' ble lagt til av noen som prøvde å rydde opp i dashbordet. Tekst-diffen lander deg på linjen på sekunder, mens å lese begge spørringene side ved side i Slack ville ta ti minutter.
Sammenligne ORM-generert SQL mellom appversjoner
Etter en Hibernate- eller SQLAlchemy-oppgradering er spørringer som var tre joins nå fire med ekstra subspørringer, eller parameterbinding gikk fra ? til $1-plassholdere. Fang SQL fra spørringsloggen på hver appversjon (psql log_statement = all, MySQL slow log eller APM-verktøyet ditt) og diff dem. Aliasnavnene blir støyete (t1, t2, generatedAlias0), men den faktiske strukturelle endringen er som regel det eneste diffen fremhever som en ekte redigering.
Validere at en DDL-refaktorering bevarer intensjonen
Du har endret navnet på user_orders til orders og delt opp en JSON-blob-kolonne i normaliserte tabeller. Lim inn pg_dump --schema-only-utskriften før og etter refaktoreringen; diffen gjør det åpenbart om du beholdt hver constraint, indeks og default. Fellen å passe på er en NOT NULL som stille forsvant under navnebyttet, eller et UNIQUE-constraint som falt ut fordi ingen la det til igjen på den nye tabellen.
Sjekke at staging-skjema samsvarer med prod
Kjør pg_dump --schema-only --no-owner mot staging og prod, og diff de to. Forskjellene burde være nøyaktig de migrasjonene som står i kø til neste deploy. Alt annet, en ekstra indeks, en annen kolonnetype, en glemt testtabell, er et tegn på skjema-drift som vil bite under selve deployen. Samme tilnærming med mysqldump --no-data for MySQL og SCRIPT TO for SQL Server, eller DataGrips skjemaeksport på tvers av enhver database.
Gjennomgå dialektportering (Postgres til MySQL)
Å portere en spørring fra PostgreSQL til MySQL eller motsatt vei betyr å holde styr på hvilke funksjoner, typer og setninger som må endres: SERIAL versus AUTO_INCREMENT, NOW() versus CURRENT_TIMESTAMP, RETURNING versus LAST_INSERT_ID(). Diff originalen mot den porterte versjonen, og alle dialektsubstitusjoner kommer frem. Diffen vil ikke validere SQL i måldialekten, så kjør den likevel gjennom psql eller mysql for å bekrefte, men linje-for-linje-visningen forteller hvilke beslutninger du må dobbeltsjekke.
SQL hurtigreferanse
Et kort jukseark over de dialekt- og parsing-ytterkasusene denne diffen oftest løfter til overflaten. Forankret i ISO SQL-standarden og dokumentasjonen til de store leverandørene.
| Topic | What this tool does |
|---|
| Dialekt-drift | PostgreSQL, MySQL, SQL Server, SQLite og Oracle utvider hver ISO SQL-standarden med egen syntaks. SERIAL, AUTO_INCREMENT, IDENTITY og GENERATED ALWAYS AS IDENTITY er fire måter å skrive den samme ideen på. |
|---|
| Identifikator-folding av store/små | PostgreSQL folder usiterte identifikatorer til små bokstaver, så Users og users er den samme tabellen. MySQL avhenger av lower_case_table_names og det underliggende filsystemet. SQL Server er som standard størrelseufølsom, men respekterer collation. Sitér identifikatorer med "Users" (standard), backticks (MySQL) eller hakeparenteser (SQL Server) for å bevare store/små. |
|---|
| Nøkkelordstørrelse | SQL-nøkkelord er størrelseufølsomme overalt, så SELECT og select er identiske for parseren. Konvensjonen er store bokstaver for nøkkelord og små for identifikatorer; de fleste stilguider og ISO-spesifikasjonen følger den. Blandet størrelse er gyldig og kjører, men verktøy som sqlfluff og sqlfmt normaliserer den. |
|---|
| Kommentarstiler | To former: -- linjekommentar (slutter ved linjeskift) og /* blokkommentar */ (ingen nøsting i standard-SQL, selv om noen dialekter tillater det). MySQL støtter også # for linjekommentarer som utvidelse. Diffen behandler kommentarer som tekst og viser kommentarredigeringer som enhver annen endring. |
|---|
| Setningsskillere | Semikolon (;) avslutter en setning i standard-SQL. De fleste klienter krever det mellom setninger i et skript. Noen klienter (SSMS) bruker i stedet GO som batchskiller, som ikke er en del av SQL-grammatikken; det er et klientdirektiv. |
|---|
| Dollar-siterte strenger (PostgreSQL) | PostgreSQL støtter $tag$ ... $tag$ for strenglitteraler slik at du ikke må escape-e enkle anførselstegn inni, særlig nyttig til funksjonskropper. $$ SELECT 'hello' $$ er gyldig og vanlig i CREATE FUNCTION-blokker. Andre dialekter parser ikke denne syntaksen. |
|---|
| Parameterbindings-plassholdere | Ingen standard. PostgreSQL og ORM-er som sikter mot det bruker $1, $2. JDBC, MySQL og ODBC bruker ?. Navngitte plassholdere :name er vanlige i Oracle og i mange ORM-strengmaler. ORM-generert SQL skiller seg ofte mellom versjoner kun i plassholderstil; formater begge sider før diff. |
|---|
| Encoding | UTF-8 er den universelle standarden for SQL-filer i 2026. Eldre skript med Windows-opphav kan fortsatt være lagret som UTF-16 LE med BOM, som dukker opp som et spøkelsestegn på linje 1 i en tekst-diff. Hvis to filer ser identiske ut, men diffen flagger en ett-tegns endring i begynnelsen, mistenk BOM-en og lagre på nytt med eksplisitt UTF-8. |
|---|
SQL-diff: ofte stilte spørsmål
Hvordan skiller dette seg fra å kjøre EXPLAIN ANALYZE på begge spørringer?
Annet lag av stacken. EXPLAIN ANALYZE viser deg planen til spørringen, det optimaliseren bestemte seg for å gjøre gitt statistikken den har. Dette verktøyet differ teksten til spørringen, det som endret seg i repoet ditt. Du vil vanligvis ha begge: denne diffen for å oppdage refaktoreringen (en jointype endret seg, et predikat flyttet seg), så EXPLAIN ANALYZE i psql eller klienten din for å bekrefte at optimaliseren faktisk valgte en fornuftig plan for den nye formen. De to utfyller hverandre, de erstatter ikke.
Er diffen dialektbevisst (PostgreSQL vs MySQL vs SQL Server)?
Nei. Diffen behandler input som tekst, så den parser ikke PostgreSQL, MySQL, SQL Server, SQLite eller Oracle ulikt og flagger ikke dialektinkompatibel syntaks. Det er bevisst: det betyr at du kan diffe på tvers av dialekter, som er nettopp det du vil når du porterer en spørring. Trenger du dialektbevisst linting, kjør SQL gjennom sqlfluff eller databasens parser separat. For gjennomgangsbruken ("hva endret seg i denne spørringen") er tekstnivå riktig granularitet.
Formaterer verktøyet SQL for meg?
Ja, Format-knappen på hver rute ombryter SQL med konsistent innrykk, nøkkelord i store bokstaver og én setning per linje. Det er en grunnleggende formatter, ikke en erstatning for sqlfmt eller sqlfluff: den skriver ikke om implisitte joins til eksplisitte, og den håndhever ikke en bestemt dialekts stilguide. Poenget er å fjerne formateringsstøy før diffen, slik at en DataGrip-formatert spørring på den ene siden og en håndskrevet på den andre sammenlignes rent.
Normaliserer den størrelsen på nøkkelord (SELECT vs select)?
Format-knappen setter nøkkelord i store bokstaver, som er konvensjonen i de fleste stilguider og i ISO SQL-standarden. Hvis du ikke klikker Format, dukker blandet størrelse opp som diff fordi motoren under er tegnbasert. SQL-nøkkelord er størrelseufølsomme i alle databaser, så select og SELECT kjører identisk. Identifikatorstørrelse er en annen sak og varierer mellom databaser; se hurtigreferansen nedenfor for hvordan Postgres, MySQL og SQL Server er forskjellige.
Hvordan håndterer jeg ORM-genererte aliaser som t1, t2, generatedAlias0?
ORM-utskrift er støyete av natur: Hibernate genererer generatedAlias0, generatedAlias1, og SQLAlchemy bruker anon_1, anon_2. Hvis to ORM-versjoner tilordner de samme aliasene i ulik rekkefølge, vil tekst-diffen fremheve hver aliasbytte som endring, selv om spørringen er strukturelt identisk. Den praktiske løsningen er å formatere begge sider, ignorere alias-bare-forskjeller (vanligvis åpenbare som parede røde og grønne blokker på samme linje) og fokusere på de ekte strukturelle redigeringene: en ny join, en annen WHERE-setning, en fjernet kolonne.
Finnes det størrelsesgrenser på SQL jeg limer inn?
Myke grenser, ikke harde. Diffen kjører i nettleseren din, så taket er nettleserens minne og hvor lenge du er villig til å vente. En 5 000-linjers pg_dump-utskrift diffes på godt under et sekund på en moderne laptop. En dump på 200 000 linjer kan ta flere sekunder og treffe minnegrenser på svakere enheter. For så store databasedumper er den riktige flyten å diffe kun skjema først (pg_dump --schema-only) og så bore ned i spesifikke tabeller hvis du trenger sammenligning på datanivå.
Personvern og hvordan det virker
SQL-en din forlater aldri nettleseren. Formatteren og diffen kjører begge på maskinen din, lokalt. Ingen analytics på input, ingen logger, ingen "hjelpsom" sky-rundtur, noe som betyr noe når SQL-en du limer inn inneholder ekte tabellnavn, ekte kolonnenavn eller ekte produksjonsdata på en eksempelrad. Språket er dokumentert i ISO/IEC 9075, og dialektreferansene er PostgreSQL, MySQL, SQL Server og SQLite.