SQL-formaterare & Validator - Formatera SQL-frågor Online Gratis
Gratis SQL-formaterare och validator. Formatera SQL automatiskt med korrekt indrag och stor/liten bokstav. Kontrollera syntaxfel direkt. Fungerar med MySQL, PostgreSQL, SQL Server, Oracle.
SQL-formaterare & Validering
Formatera och validera SQL-frågor med automatisk indragning, nyckelordskapitalisering och syntaxfelidentifiering.
Dokumentation
Varför SQL-formatering spelar roll
Har du någonsin ärvt ett databasprojekt där SQL:en ser ut som om någon skrivit den med förbundna ögon? Du är inte ensam. Dåligt formaterad SQL är en av de vanligaste källorna till buggar och bortkastad tid inom databasutveckling.
Denna SQL-formaterare och validator hjälper dig att städa upp röriga frågor automatiskt. Klistra in din SQL, och den applicerar omedelbart korrekt indentation, kapitaliserar nyckelord och kontrollerar syntaxfel—allt i din webbläsare utan att skicka data till någon server. Det som vanligtvis tar 10-15 minuter av manuell formatering sker på några sekunder.
Av min erfarenhet av att arbeta med databasteam är den största tidsbespararen inte bara formateringen—utan att fånga fel innan de når produktionen. En felplacerad parentes eller en oavslutad citattecken kan slösa bort timmar av felsökning. Detta verktyg fångar sådana problem omedelbart, innan du exekverar något mot din databas.
Hur man använder SQL-formateraren
Gränssnittet är avsiktligt minimalt—bara klistra in och kör:
- Klistra in din SQL i inmatningsrutan (eller skriv direkt om du skapar från grunden)
- Se den formateras automatiskt när du skriver—inga knappar att klicka på, inga inställningar att konfigurera
- Granska valideringsfel om några visas under den formaterade utdatan
- Kopiera den formaterade SQL:en med ett klick för att använda i din IDE, dokumentation eller databasverktyg
Fungerar på vilken enhet som helst med en webbläsare. Formateringen sker helt på klientsidan, så dina frågor lämnar aldrig din maskin—viktigt när du arbetar med produktionsdatabasstrukturer eller känsliga scheman.
Vad SQL-formateraren gör
Nyckelordsskrivning med versaler
Alla SQL-nyckelord skrivs automatiskt med versaler—SELECT, FROM, WHERE, JOIN, och så vidare. Detta följer konventionen som används av de flesta databasteam och gör nyckelord visuellt åtskilda från dina tabell- och kolumnnamn. När du scannar igenom en komplex fråga hjälper denna visuella separation dig att identifiera frågestrukturen på en gång.
Smart Indragning
Formateraren strukturerar din SQL baserat på logisk hierarki snarare än att bara lägga till slumpmässiga radbrytningar. Huvudsakliga satser som SELECT och FROM börjar vid vänster marginal. JOIN-satser dras in under FROM för att visa att de är en del av tabellvalet. Delförfrågningar får ytterligare indragningsnivåer, vilket gör kapslad logik tydlig.
Här är vad som händer i praktiken: när du har en fråga med flera kopplingar och delförfrågningar, låter korrekt indragning dig se frågestrukturen utan att läsa varje ord. Du kan omedelbart se var en koppling slutar och en annan börjar, eller var en delförfrågan används i din SELECT-lista.
Logiska Radbrytningar
Radbrytningar visas där de förbättrar läsbarheten, inte bara överallt. Varje huvudsaklig sats får sin egen rad. Objekt i kommaseparerade listor (som kolumnnamn i SELECT) får varsin rad med korrekt indragning. Delförfrågningar är visuellt separerade. CASE-satser bryts vid WHEN, THEN, och ELSE för tydlighet.
Mellanrummen följer SQL Style Guide-konventionerna som används inom branschen, vilket innebär att din formaterade SQL kommer att se bekant ut för andra utvecklare.
SQL-validering: Vad som kontrolleras
Validatorn fångar upp de fel som vanligtvis smyger sig igenom när du skriver SQL snabbt. Den ersätter inte din databas frågeanalysator, men den fångar vanliga misstag innan du ens kör frågan.
Strukturella fel
Obalanserade parenteser är överraskande vanliga i komplexa frågor med kapslade underfrågor. Validatorn räknar öppnande och stängande parenteser för att omedelbart flagga avvikelser. Jag har sett produktionsincidenter orsakade av en enda saknad parentes i en 200 rader lång fråga—detta fångar dem tidigt.
Ej avslutade strängliteraler inträffar när du glömmer den avslutande citattecken på ett strängvärde. Din databas kommer att avvisa dessa omedelbart, men att fånga dem här sparar en onödig tur.
Problem med klausordning flaggas när klausuler visas i fel sekvens. Till exempel, om du placerar HAVING före GROUP BY, eller WHERE efter GROUP BY, varnar validatorn dig. Detta följer SQL-standardens syntaxregler definierade i ISO/IEC 9075 SQL-standarden.
Logiska fel
JOIN-klausuler utan ON-villkor skapar oavsiktliga korssammanslagningar som returnerar många fler rader än avsett. Ett vanligt scenario: du lägger till ett tredje eller fjärde bord i en fråga och glömmer ON-klausulen. Utan denna kontroll kanske du inte märker förrän du ser tusentals duplicerade rader i dina resultat.
HAVING utan GROUP BY är tekniskt sett ogiltig SQL i de flesta databaser. HAVING-klausulen filtrerar grupperade resultat, så den kräver en GROUP BY för att fungera. Validatorn fångar denna logiska avvikelse.
Ofullständiga WHERE-villkor inträffar när du börjar skriva ett villkor men inte avslutar det—som WHERE status = utan något värde. Dessa är lätta att missa när du redigerar frågor.
Vad den inte kommer att fånga
Denna validator fokuserar på syntax och struktur, inte databasschema. Den kommer inte att veta om:
- Dina tabell- eller kolumnnamn finns i din databas
- Du slår samman kompatibla datatyper
- Din fråga kommer att prestera bra eller har optimeringsproblem
- Du har behörighet att komma åt de tabeller du frågar
Tänk på den som en första kontroll innan du skickar frågan till din faktiska databas.
Formateringsregler som tillämpas av detta verktyg
Formateraren tillämpar konsekventa regler baserade på SQL Style Guide-konventioner som de flesta databasteam följer.
Nyckelord får stor bokstav
Varje SQL-nyckelord blir versaler: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP. Detta inkluderar satser (FROM, WHERE, GROUP BY, HAVING, ORDER BY), join-typer (JOIN, INNER JOIN, LEFT JOIN), operatorer (AND, OR, NOT, IN, BETWEEN, LIKE), och vanliga funktioner (COUNT, SUM, AVG, CASE, WHEN).
Varför versaler? Det skapar visuell åtskillnad mellan SQL:s språkelement och dina databasspecifika namn (tabeller, kolumner, alias). När du skannar en fråga fångar ögat omedelbart strukturen.
Två mellanslag indrag per nivå
Huvudsatser som SELECT och FROM börjar vid vänster marginal. JOIN-satser indragna två mellanslag under FROM för att visa att de är en del av tabellvalet. Delförfrågningar indragna ytterligare två mellanslag för varje nästningsnivå. Detta skapar en visuell hierarki som matchar den logiska strukturen.
Kommaseparerade listor (kolumnnamn i SELECT, till exempel) får varsin rad med konsekvent indrag. När du har 15 kolumner i din SELECT-lista gör detta det lätt att skanna och hitta specifika kolumner.
Villkor i WHERE-satser riktas vertikalt. När du har flera AND- eller OR-villkor gör justering den logiska strukturen omedelbart uppenbar.
Före och efter: Se skillnaden
Före formatering:
1select u.id, u.name, o.order_date from users u join orders o on u.id = o.user_id where o.status = "completed" group by u.id order by u.name;
2Efter formatering:
1SELECT
2 u.id,
3 u.name,
4 o.order_date
5FROM users u
6 JOIN orders o ON u.id = o.user_id
7WHERE
8 o.status = "completed"
9GROUP BY
10 u.id
11ORDER BY
12 u.name;
13Valideringsregler: Vad som flaggas
Validatorn kontrollerar strukturell integritet och grundläggande logisk konsekvens. Här är vad den letar efter:
Strukturella kontroller
Balanserade parenteser: Öppnande och stängande parenteser måste matcha. Kapslade delförfrågningar har ofta flera nivåer av parenteser, och att räkna fel är ett av de vanligaste SQL-felen. Validatorn räknar dem åt dig.
Korrekt avslutade strängar: Varje öppnande citattecken (enkelt eller dubbelt) behöver ett avslutande citattecken. Det låter uppenbart, men när du skriver en komplex förfrågan med flera stränglitteraler är det lätt att missa ett.
Korrekt klausulordning: SQL har specifika ordningskrav. SELECT kommer före FROM, som kommer före WHERE, som kommer före GROUP BY, som kommer före HAVING, som kommer före ORDER BY. Att placera dem i fel ordning orsakar omedelbara syntaxfel. Validatorn kontrollerar denna ordning baserat på SQL-standarden.
Logiska konsekvenskontroller
JOIN med ON-villkor: Varje JOIN behöver en ON- eller USING-klausul för att specificera hur tabeller relaterar. Utan den får du en korsvis koppling—varje rad från en tabell parad med varje rad från en annan. Det är sällan det du vill och indikerar vanligtvis en saknad ON-klausul.
Fullständiga WHERE-villkor: En WHERE-klausul behöver fullständiga predikat. WHERE status = utan värde är ofullständigt och ogiltigt. Validatorn flaggar dessa partiella villkor.
HAVING kräver GROUP BY: HAVING-klausulen filtrerar grupperade resultat, så den har bara mening när du har en GROUP BY. Att använda HAVING utan GROUP BY är ett logiskt fel som de flesta databaser avvisar.
GROUP BY aggregeringsregler: När du använder aggregeringsfunktioner som COUNT() eller SUM() måste alla icke-aggregerade kolumner i din SELECT-lista visas i GROUP BY. Detta är ett grundläggande SQL-krav som validatorn kontrollerar.
Exempel på vanliga fel som fångas
Här är SQL med flera problem som validatorn skulle flagga:
1SELECT user_id, COUNT(*) FROM orders
2JOIN users
3WHERE status =
4GROUP BY
5HAVING count > 10;
6Identifierade problem:
JOIN userssaknarON-villkor (kommer skapa korsvis koppling)WHERE status =ofullständigt (inget jämförelsevärde)- Tom
GROUP BY-klausul (inga kolumner specificerade) HAVING count > 10refererar till odefinierad kolumn
När du ska använda denna SQL-formaterare
Under kodgranskningar
Har du någonsin försökt granska en 50-raders SQL-fråga som är skriven på en enda rad? Det är brutalt. Innan du skickar in frågor för kodgranskning, kör dem genom formateraren. Dina granskare kommer att tacka dig, och de kommer faktiskt att kunna fokusera på logik istället för att tyda strukturen.
När du granskar pull requests med databasändringar, be bidragsgivare att formatera sin SQL först. Det gör det mycket lättare att hitta logiska fel när strukturen är konsekvent.
Felsöka produktionsproblem
När du felsöker en misslyckad fråga i produktionen hjälper korrekt formatering dig att se strukturen tydligt. Jag har felsökt otaliga frågor där problemet blev uppenbart så snart SQL:en var korrekt formaterad—en saknad join-villkor, en felaktig WHERE-sats gruppering eller en underförfrågan på fel plats.
Kopiera frågan från dina loggar, klistra in den här, och du kommer omedelbart att se om det finns strukturella problem.
Arbeta med genererad SQL
ORMs (Object-Relational Mappers) som Hibernate, Entity Framework eller SQLAlchemy genererar SQL automatiskt. Ibland behöver du se vilken fråga de faktiskt producerar. Den genererade SQL:en är vanligtvis en lång rad utan formatering. Detta verktyg gör ORM-genererade frågor läsbara så att du kan förstå och optimera dem.
Undervisa och lära sig SQL
Om du lär dig SQL eller undervisar i det, hjälper denna formaterare dig att förstå rätt frågestruktur. När du klistrar in en fungerande fråga och ser hur den formateras, lär du dig konventionerna. När du klistrar in en trasig fråga och ser valideringsfel, förstår du varför den inte fungerar.
Migrera mellan databassystem
Olika databaser (PostgreSQL, MySQL, SQL Server) har något olika SQL-dialekter. När du migrerar frågor mellan system hjälper korrekt formatering dig att upptäcka dialektspecifik syntax som kan behöva justeras. Formateraren följer standard SQL-konventioner som fungerar i de flesta större databaser.
Alternativ till denna SQL-formaterare
Databasspecifika IDE:er
Verktyg som DataGrip, SQL Server Management Studio eller MySQL Workbench har inbyggda formaterare. De är kraftfulla och integreras direkt med dina databasanslutningar.
Kompromissen: de kräver installation och inställning. DataGrip kostar 199 USD/år för enskilda användare. SSMS är gratis men endast för Windows. Om du behöver snabb formatering utan installation eller arbetar över flera databassystem, är ett webbläsarbaserat verktyg mer praktiskt.
Editorförlängningar
Om du skriver SQL i VS Code eller Sublime Text, ger tillägg som SQL Beautify eller SqlBeautifier formatering direkt i din editor. Detta fungerar väl när du aktivt skriver frågor och vill omedelbar formatering som en del av din arbetsprocess.
Begränsningen: tillägg behöver konfiguration och är knutna till din specifika editor. När du delar SQL med teammedlemmar eller publicerar frågor i dokumentation, säkerställer en standardiserad webbformaterare att alla ser samma formatering.
Kommandoradsformaterare
Verktyg som sqlformat (Python) eller sql-formatter-cli (Node.js) kan integreras i CI/CD-pipelines för att automatiskt formatera SQL i versionskontroll. Detta säkerställer konsekvens över ett team.
Bäst använda för automatiserade arbetsflöden snarare än ad hoc-formatering. Om du bara rensar några frågor eller lär dig SQL, lägger kommandoradsverktyg onödig komplexitet.
Hur SQL-formatering blev standard praxis
SQL utvecklades på IBM på 1970-talet, men formateringskonventioner uppstod mycket senare. Tidig SQL var funktionell men inkonsekvent—varje utvecklare formaterade frågor olika.
Vändpunkten kom på 1990-talet när databaser övergick från enskilda utvecklarprojekt till teambaserad utveckling. Organisationer började skapa interna SQL-stilguider för att upprätthålla konsekvens. När fem utvecklare arbetade på samma databas blev läsbar SQL avgörande för samarbetet.
2000-talet introducerade ORMs som genererade SQL automatiskt. Dessa verktyg producerade fungerande men ful SQL—allt på en rad, ingen indentation. Detta skapade efterfrågan på automatiska formaterare som kunde göra genererad SQL läsbar för människor.
Online SQL-formaterare dök upp på 2010-talet när webbutveckling mognade. Istället för att installera verktyg eller konfigurera IDE-plugins kunde utvecklare formatera SQL i en webbläsare. Detta demokratiserade tillgången till korrekt formatering för alla från nybörjare som lär sig SQL till erfarna utvecklare som rensar snabba frågor.
Idag betraktas SQL-formatering som en grundläggande praxis, liknande kodformatering i andra programmeringsspråk. SQL Style Guide av Simon Holywell tillhandahåller brett accepterade konventioner, och verktyg som detta implementerar dessa standarder automatiskt.
Kodexempel
Exempel 1: Grundläggande SELECT-fråga
Oformaterad:
1select id, first_name, last_name, email from customers where status = 'active' order by last_name, first_name;
2Formaterad:
1SELECT
2 id,
3 first_name,
4 last_name,
5 email
6FROM
7 customers
8WHERE
9 status = 'active'
10ORDER BY
11 last_name,
12 first_name;
13Exempel 2: JOIN-fråga
Oformaterad:
1select c.id, c.name, o.order_date, o.total_amount from customers c left join orders o on c.id = o.customer_id where o.order_date >= '2023-01-01' and o.status != 'cancelled' order by o.order_date desc;
2Formaterad:
1SELECT
2 c.id,
3 c.name,
4 o.order_date,
5 o.total_amount
6FROM
7 customers c
8 LEFT JOIN orders o ON c.id = o.customer_id
9WHERE
10 o.order_date >= '2023-01-01'
11 AND o.status != 'cancelled'
12ORDER BY
13 o.order_date DESC;
14Exempel 3: Komplex fråga med underfråga
Oformaterad:
1select d.department_name, (select count(*) from employees e where e.department_id = d.id) as employee_count, (select avg(salary) from employees e where e.department_id = d.id) as avg_salary from departments d where d.active = true having employee_count > 0 order by avg_salary desc;
2Formaterad:
1SELECT
2 d.department_name,
3 (
4 SELECT
5 COUNT(*)
6 FROM
7 employees e
8 WHERE
9 e.department_id = d.id
10 ) AS employee_count,
11 (
12 SELECT
13 AVG(salary)
14 FROM
15 employees e
16 WHERE
17 e.department_id = d.id
18 ) AS avg_salary
19FROM
20 departments d
21WHERE
22 d.active = TRUE
23HAVING
24 employee_count > 0
25ORDER BY
26 avg_salary DESC;
27Programmatisk SQL-formatering
Här är exempel på hur man implementerar SQL-formatering i olika programmeringsspråk:
1// JavaScript SQL-formateringsexempel med sql-formatter-biblioteket
2const sqlFormatter = require('sql-formatter');
3
4function formatSQL(sql) {
5 return sqlFormatter.format(sql, {
6 language: 'sql',
7 uppercase: true,
8 linesBetweenQueries: 2,
9 indentStyle: 'standard'
10 });
11}
12
13const rawSQL = "select id, name from users where status='active'";
14const formattedSQL = formatSQL(rawSQL);
15console.log(formattedSQL);
161# Python SQL-formateringsexempel med sqlparse
2import sqlparse
3
4def format_sql(sql):
5 return sqlparse.format(
6 sql,
7 reindent=True,
8 keyword_case='upper',
9 identifier_case='lower',
10 indent_width=2
11 )
12
13raw_sql = "select id, name from users where status='active'"
14formatted_sql = format_sql(raw_sql)
15print(formatted_sql)
161// Java SQL-formateringsexempel med JSqlParser
2import net.sf.jsqlparser.parser.CCJSqlParserUtil;
3import net.sf.jsqlparser.statement.Statement;
4
5public class SQLFormatter {
6 public static String formatSQL(String sql) throws Exception {
7 Statement statement = CCJSqlParserUtil.parse(sql);
8 return statement.toString()
9 .replaceAll("(?i)SELECT", "\nSELECT")
10 .replaceAll("(?i)FROM", "\nFROM")
11 .replaceAll("(?i)WHERE", "\nWHERE")
12 .replaceAll("(?i)ORDER BY", "\nORDER BY");
13 }
14
15 public static void main(String[] args) throws Exception {
16 String rawSQL = "select id, name from users where status='active'";
17 String formattedSQL = formatSQL(rawSQL);
18 System.out.println(formattedSQL);
19 }
20}
211<?php
2// PHP SQL-formateringsexempel
3function formatSQL($sql) {
4 // Ersätt nyckelord med versaler
5 $keywords = ['SELECT', 'FROM', 'WHERE', 'JOIN', 'LEFT JOIN', 'RIGHT JOIN',
6 'INNER JOIN', 'GROUP BY', 'ORDER BY', 'HAVING', 'LIMIT'];
7
8 $formattedSQL = $sql;
9 foreach ($keywords as $keyword) {
10 $formattedSQL = preg_replace('/\b' . preg_quote($keyword, '/') . '\b/i', "\n$keyword", $formattedSQL);
11 }
12
13 // Lägg till indrag
14 $lines = explode("\n", $formattedSQL);
15 $result = '';
16 $indentLevel = 0;
17
18 foreach ($lines as $line) {
19 $trimmedLine = trim($line);
20 if (!empty($trimmedLine)) {
21 $result .= str_repeat(" ", $indentLevel) . $trimmedLine . "\n";
22 }
23 }
24
25 return $result;
26}
27
28$rawSQL = "select id, name from users where status='active'";
29$formattedSQL = formatSQL($rawSQL);
30echo $formattedSQL;
31?>
32Vanliga frågor
Fungerar denna SQL-formaterare med PostgreSQL, MySQL och SQL Server?
Ja, den hanterar standard SQL-syntax som är gemensam för större databaser—PostgreSQL, MySQL, SQL Server (T-SQL), Oracle, SQLite och MariaDB. Formateraren fokuserar på kärn-SQL som fungerar överallt: SELECT, JOIN, WHERE, GROUP BY, och så vidare.
Databasspecifika funktioner kanske inte formateras perfekt. Till exempel kanske PostgreSQL:s array-syntax eller SQL Server:s egna funktioner inte får särskild formateringsbehandling, men de kommer inte heller att störa formateraren. Förfrågan kommer fortfarande att vara mer läsbar än tidigare.
Skickas min SQL-kod till en server?
Nej. Allt sker i din webbläsare. Klistra in din SQL, och den formateras lokalt utan några nätverksförfrågningar. Dina förfrågningar lämnar aldrig din maskin.
Detta är viktigt när du arbetar med produktionsdatabassystem eller konfidentiell affärslogik. Det finns ingen risk att känslig information loggas eller lagras på någon annans server.
Kan validatorn fånga alla SQL-fel?
Långt ifrån. Den fångar strukturella och syntaktiska problem—saknade parenteser, oavslutade citattecken, satser i fel ordning. Det är allt.
Den kommer inte att veta om dina tabellnamn är felaktiga, om datatyper är inkompatibla eller om din förfrågan kommer att ta 10 minuter att köra. För det behöver du din faktiska databas. Tänk på denna validator som stavningskontroll för SQL, inte en fullständig frågeanalysator.
Varför formatera SQL när min databas kör den oavsett?
Databaser bryr sig inte om formatering—de tolkar förfrågan oavsett. Men människor bryr sig. När du behöver felsöka en misslyckad förfrågan, modifiera en befintlig eller granska någon annans SQL, gör korrekt formatering skillnaden mellan att förstå den på 30 sekunder eller 30 minuter.
Formaterad SQL hjälper dig också att upptäcka logiska fel. När strukturen är tydlig kan du se om du har kopplat tabeller felaktigt eller placerat villkor på fel plats.
Kan jag anpassa indrag eller nyckelordens stil?
För närvarande inte. Formateraren använder standardkonventioner: versala nyckelord, två mellanslags indrag, satser på separata rader. Dessa följer SQL Style Guide som de flesta team använder.
Om du behöver anpassad formatering (olika indragsbredd, gemena nyckelord), behöver du ett konfigurerbart kommandoradsverktyg som sqlformat eller en IDE med formateringsinställningar.
Fungerar detta med 1000-radiga lagrade procedurer?
Den formaterar stora förfrågningar, även om mycket komplexa lagrade procedurer (1000+ rader) kan ta några sekunder att bearbeta. Formateraren hanterar den SQL du klistrar in, oavsett längd.
För massiva lagrade procedurer kan du vilja dela upp dem i mindre delar eller använda en databasspecifik IDE som är optimerad för stora filer.
Ändrar formatering hur min förfrågan exekveras?
Nej. Formatering lägger bara till mellanslag och ändrar versaler. Din databas ignorerar båda. Den formaterade förfrågan returnerar exakt samma resultat och körs med samma prestanda som den oformaterade versionen.
Det enda undantaget är om validatorn hittar faktiska syntaxfel (saknade parenteser, etc.), där korrigeringen kommer att ändra beteendet—men bara från "körs inte" till "körs korrekt".
Vilken SQL-standard följer detta?
Formateraren följer SQL-92-konventioner med tillägg för vanliga funktioner i SQL:1999 och senare standarder. Detta täcker den SQL som de flesta utvecklare skriver dagligen—SELECT-förfrågningar, kopplingar, underförfrågningar, CASE-satser, fönsterfunktioner.
Mycket nya SQL-funktioner från SQL:2016 eller SQL:2019 kanske inte känns igen, men de kommer inte att störa formateraren. Du får bara grundläggande formatering istället för specialiserad hantering.
Kan jag använda detta för Oracle PL/SQL eller SQL Server T-SQL?
För grundläggande förfrågningar, ja. För procedurkod (PL/SQL-block, T-SQL lagrade procedurer med kontrollflöde) kommer formateringen att vara begränsad. Verktyget fokuserar på SELECT, INSERT, UPDATE, DELETE-satser och deras satser.
Om du arbetar mycket med databasspecifik procedurkod kommer databasens inbyggda IDE (SQL Developer för Oracle, SSMS för SQL Server) att ge bättre formatering som förstår den fullständiga syntaxen.
Referenser och vidare läsning
- SQL Style Guide av Simon Holywell - Den facto-standarden för SQL-formateringskonventioner som används av utvecklingsteam
- ISO/IEC 9075 SQL-standard - Den officiella internationella SQL-standardspecifikationen
- PostgreSQL SQL-syntaxdokumentation - PostgreSQL:s omfattande SQL-syntaxreferens
- Microsoft T-SQL-referens - Officiell dokumentation för SQL Server:s T-SQL-dialekt
- MySQL-referensmanual - MySQL:s kompletta SQL-uttrycksreferens
Börja Formatera Din SQL
Läsbar SQL gör felsökning snabbare, kodgranskningar enklare och samarbete smidigare. Klistra in din fråga ovanför för att se den formaterad enligt branschstandard—ingen installation, ingen konfiguration, ingen data lämnar din webbläsare.