SQL-formaterare

Klistra in en enradig SQL-sats kopierad från en logg eller en ORM, så bryter formateraren upp den i indenterade satser med konsekvent nyckelordsskiftläge, nyrader före SELECT, FROM, WHERE, GROUP BY, och justerade kolumner i projektionen. Stöder dialekterna MySQL, PostgreSQL, SQL Server, Oracle, SQLite och BigQuery, var och en har något olika nyckelord och reserverade ord.

Så fungerar formateringen

  1. 1

    Klistra in din SQL

    Enradigt klump, minifierad utdata från Hibernate, vad som helst. Flera satser åtskilda med `;` formateras alla.

  2. 2

    Välj dialekt och stil

    Dialekten styr nyckelordslistan; stilen styr kommaplacering (inledande vs efterföljande), indenteringsbredd och versala/gemena nyckelord.

  3. 3

    Tokens tolkas, ersätts inte med regex

    En tokenizer hanterar strängar, kommentarer, parenteser och subqueries korrekt. Stränglitteraler bevaras ordagrant.

  4. 4

    Kopiera den formaterade utdatan

    Validerad SQL: samma semantik, renare layout.

Före och efter

Före:

SELECT u.id,u.name,COUNT(o.id) AS orders FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at>='2024-01-01' GROUP BY u.id,u.name HAVING COUNT(o.id)>5 ORDER BY orders DESC LIMIT 50;

Efter (inledande komma, versala nyckelord, 2-stegs indentering):

SELECT
    u.id
  , u.name
  , COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o
  ON o.user_id = u.id
WHERE u.created_at >= '2024-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY orders DESC
LIMIT 50;

Stilval som spelar roll

  • Versala vs gemena nyckelord. VERSALER är traditionellt och lätt att skanna. Gemener är renare i moderna kodredigerare med syntaxmarkering.
  • Inledande vs efterföljande kommatecken. Inledande ( , col) gör det lättare att kommentera bort en enskild kolumn. Efterföljande (col,) läses mer naturligt i text.
  • Kommaplacering i GROUP BY. Ofta ett per rad för långa satser, inline för korta.
  • JOIN-indentering. ON på nästa rad (hängande indentering) vs på samma rad. Långa villkor drar nytta av hängande.
  • Subqueries. Indentera hela subquerien, inte bara den inledande parentesen.

Dialektspecifika fallgropar

  • MySQL-backticks vs PostgreSQL-dubbelcitat för identifierare.
  • WITH-CTE:er, MS SQL har ett krav på ; före WITH; formateraren hanterar det.
  • Fönsterfunktioner, långa OVER (...)-satser drar nytta av radbrutna PARTITION BY och ORDER BY.
  • BigQuery har ARRAY_AGG, STRUCT och tabellsuffix (*_yyyymmdd) som tokenizern inte får bryta.
  • Oracle har (+)-syntax för outer join, formateraren bevarar den men flaggar den som äldre.

Vad formateraren inte gör

  • Fixar buggar, en ogiltig JOIN förblir ogiltig.
  • Expanderar SELECT *, kolumnlistor härleds inte från schema.
  • Optimerar frågor, endast layout, inte exekveringsplaner.
  • Skriver om subqueries som CTE:er, en annan fråga.

Vanliga frågor

Nej, den är rent kosmetisk. Blanksteg, nyrader och kommaplacering flyttas runt, men nyckelord, operatorer, litteraler och identifierare bevaras exakt.

Stöds, CREATE TABLE, ALTER, CREATE PROCEDURE, triggers. Formateraren hanterar blockkonstruktioner (BEGIN ... END) och radfortsättningar inuti procedurer.

Det borde den inte göra, om den gör det är det troligen en dialektmissmatchning. Försök byta dialekt. Rapportera gärna ihållande fel; vi behandlar dem som buggar.

Flink SQL och Cassandra CQL ser likadana ut men har dialektspecifika nyckelord som vanliga formaterare förvanskar. Använd med försiktighet och verifiera att utdatan kör.

Relaterade verktyg

Verktyget finns på andra språk