Formater SQL
Format and beautify SQL queries. Paste messy SQL and get clean, indented output with syntax highlighting.
Najwazniejsze funkcje
- Automatyczne wielkie litery słów kluczowych
- Konfigurowalne wcięcia
- Podświetlanie składni
- Obsługa popularnych dialektów SQL
Guide
Formatowanie SQL przekształca gęste, nieczytelne zapytania w ustrukturyzowany, spójnie wcięty kod, który jest łatwy do czytania, przeglądania, debugowania i utrzymania. Zapytanie, które działa idealnie, gdy jest napisane jako jedna linia, staje się ciężarem utrzymania, gdy ktoś inny (lub Ty, trzy miesiące później) musi zrozumieć, co robi. Spójne formatowanie SQL to nie kosmetyka. Redukuje błędy, przyspiesza przegląd kodu i czyni złożone zapytania ustrukturyzowanymi. Ten przewodnik obejmuje konwencje formatowania, strukturę klauzul, powszechne wzorce dla różnych typów zapytań i to, jak formatowanie wchodzi w interakcję z optymalizacją zapytań. Fundamentalna zasada formatowania SQL to jedna klauzula na linię. SELECT, FROM, WHERE, JOIN, ON, GROUP BY, HAVING, ORDER BY, LIMIT, INSERT INTO, VALUES, UPDATE, SET i DELETE FROM każda zaczyna się we własnej linii na bazowym poziomie wcięcia. Ta struktura czyni zapytanie skanowalnym. Możesz zobaczyć na pierwszy rzut oka, jakie kolumny są wybrane, które tabele są zaangażowane, jakie warunki filtrują dane i jak wyniki są uporządkowane. Zapytanie sformatowane w ten sposób czyta się jak ustrukturyzowany dokument, a nie jak zdanie bez przecinków. Formatowanie klauzuli SELECT wylistowuje każdą kolumnę we własnej linii, wciętej jeden poziom od słowa kluczowego SELECT. Wiodące przecinki (przecinki na początku każdej linii zamiast na końcu) to popularna konwencja, bo ułatwiają komentowanie pojedynczych kolumn i produkują czystsze diffy w kontroli wersji. Zarówno końcowe, jak i wiodące przecinki są akceptowalne, o ile wybór jest spójny w całej bazie kodu. Aliasy kolumn powinny używać słowa kluczowego AS jawnie (column_name AS alias) zamiast skrótu (column_name alias) dla jasności. Gdy wyrażenie kolumny jest długie (instrukcja CASE lub wywołanie funkcji z wieloma argumentami), umieść je we własnej linii i wcięj kontynuację. Klauzule FROM i JOIN korzystają ze spójnego wyrównania. Każdy JOIN dostaje własną linię na tym samym wcięciu co FROM. Warunek ON jest wcięty poniżej swojego JOIN. Dla zapytań z wieloma złączeniami ta wizualna struktura czyni relacje tabeli jasnymi: FROM orders o JOIN customers c ON c.customer_id = o.customer_id JOIN products p ON p.product_id = o.product_id LEFT JOIN shipping s ON s.order_id = o.order_id Typ złączenia (INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN) niesie znaczenie. Formatowanie, które wizualnie oddziela każde złączenie, pomaga recenzentom zweryfikować, że poprawny typ złączenia jest użyty dla każdej relacji. LEFT JOIN, który powinien być INNER JOIN (lub odwrotnie), to powszechny błąd, który sformatowany kod ułatwia do zauważenia. Formatowanie klauzuli WHERE umieszcza każdy warunek we własnej linii z AND lub OR na początku linii. Wcinanie warunków poniżej WHERE czyni logikę filtra widoczną: WHERE o.order_date >= '2026-01-01' AND o.status = 'completed' AND c.country = 'US' AND (p.category = 'electronics' OR p.category = 'appliances') Złożona logika boolowska z mieszanymi operatorami AND i OR to powszechne źródło błędów. Formatowanie z jawnymi nawiasami i jasnym wcięciem pokazuje logiczne grupowanie. Bez formatowania WHERE a = 1 AND b = 2 OR c = 3 jest niejednoznaczne dla ludzkich czytelników (choć SQL ocenia AND przed OR, więc oznacza (a = 1 AND b = 2) OR c = 3). Sformatowane z nawiasami intencja staje się jasna. Zawsze używaj nawiasów z mieszanym AND/OR, by uczynić pierwszeństwo jawne. Podzapytania powinny być wcięte jeden poziom wewnątrz swoich nawiasów. Każde podzapytanie jest formatowane używając tych samych zasad co zapytanie najwyższego poziomu. Skorelowane podzapytania (te odnoszące się do kolumn z zapytania zewnętrznego) są szczególnie ważne do jasnego formatowania, bo ich relacja do zapytania zewnętrznego determinuje ich zachowanie: SELECT customer_name , total_spent FROM customers c WHERE total_spent > ( SELECT AVG(total_spent) FROM customers WHERE country = c.country ) Wcięcie pokazuje, że podzapytanie jest zagnieżdżone wewnątrz klauzuli WHERE i odnosi się do c.country z zapytania zewnętrznego. Dla głęboko zagnieżdżonych podzapytań (trzy lub więcej poziomów) rozważ refaktoryzację do CTE, bo głębokie zagnieżdżanie staje się trudne do śledzenia niezależnie od formatowania. Common Table Expressions (CTE) używające klauzul WITH powinny być formatowane z każdym CTE jako osobny nazwany blok: WITH monthly_sales AS ( SELECT DATE_TRUNC('month', order_date) AS month , SUM(amount) AS total FROM orders GROUP BY DATE_TRUNC('month', order_date) ), monthly_avg AS ( SELECT AVG(total) AS avg_total FROM monthly_sales ) SELECT m.month , m.total , a.avg_total FROM monthly_sales m CROSS JOIN monthly_avg a WHERE m.total > a.avg_total CTE to jedna z najbardziej potężnych funkcji SQL do rozbijania złożonych zapytań na czytelne, testowalne komponenty. Każde CTE może być testowane niezależnie przez uruchomienie tylko swojej instrukcji SELECT. Prawidłowe formatowanie czyni cel każdego CTE widocznym i przepływ danych między CTE śledzonym. Nazywaj swoje CTE opisowo: monthly_sales jest lepsze niż cte1. Klauzule GROUP BY i ORDER BY następują według tego samego wieloliniowego wzorca co SELECT, gdy odnoszą się do wielu kolumn. Wylistuj każdą kolumnę we własnej wciętej linii. Dla GROUP BY to ułatwia weryfikację, że wszystkie niezagregowane kolumny SELECT są uwzględnione (wymóg w standardowym SQL i egzekwowane przez PostgreSQL, choć MySQL jest pobłażliwy domyślnie). Dla ORDER BY wylistowanie każdej kolumny sortowania z jej kierunkiem (ASC lub DESC) w osobnej linii wyjaśnia priorytet sortowania. Jawne stawianie ASC (nawet jeśli jest domyślne) poprawia czytelność. Formatowanie klauzuli HAVING następuje według tych samych zasad co WHERE. HAVING filtruje grupy po agregacji, a jego warunki powinny być formatowane z jednym warunkiem na linię. Powszechnym błędem formatowania jest umieszczanie warunków HAVING w klauzuli WHERE lub odwrotnie. WHERE filtruje wiersze przed grupowaniem. HAVING filtruje grupy po agregacji. Prawidłowe umiejscowienie jest istotne zarówno dla poprawności, jak i wydajności, a jasne formatowanie ułatwia weryfikację. Wyrażenia CASE to wieloliniowe konstrukty, które powinny być sformatowane, by pokazać każdą parę WHEN/THEN: SELECT order_id , CASE WHEN status = 'shipped' THEN 'In Transit' WHEN status = 'delivered' THEN 'Complete' WHEN status = 'returned' THEN 'Returned' ELSE 'Processing' END AS status_label FROM orders Zagnieżdżone wyrażenia CASE (CASE wewnątrz CASE) powinny być unikane, gdy możliwe, bo stają się nieczytelne niezależnie od formatowania. Zrefaktoryzuj do CTE, kolumn obliczeniowych lub tabeli odnośników dołączonej do zapytania zamiast tego. Instrukcje INSERT mają dwa powszechne formaty. Dla wstawiń pojedynczego wiersza z nazwanymi kolumnami wylistuj każdą parę kolumna-wartość czytelnie: INSERT INTO customers ( customer_name , email , country , created_at ) VALUES ( 'John Doe' , 'john@example.com' , 'US' , CURRENT_TIMESTAMP ) Wyrównanie wpisów VALUES z ich odpowiednimi nazwami kolumn ułatwia weryfikację, że każda wartość pasuje do poprawnej kolumny. Dla instrukcji INSERT...SELECT sformatuj część SELECT używając standardowych zasad formatowania SELECT. Instrukcje UPDATE korzystają z formatowania każdego przypisania SET we własnej linii: UPDATE customers SET email = 'newemail@example.com' , updated_at = CURRENT_TIMESTAMP , status = 'verified' WHERE customer_id = 12345 Ta struktura czyni jasnym, które kolumny są modyfikowane, i zapobiega przypadkowemu pominięciu klauzuli WHERE, która zaktualizowałaby każdy wiersz w tabeli. Klauzula WHERE w instrukcjach UPDATE i DELETE to najbardziej krytyczna klauzula do poprawnego napisania. Formatowanie, które umieszcza WHERE we własnej linii na tym samym poziomie co UPDATE lub DELETE, czyni jego obecność (lub brak) oczywistą. Instrukcje DELETE powinny zawsze mieć swoją klauzulę WHERE wyraźnie widoczną: DELETE FROM order_items WHERE order_id = 12345 AND item_status = 'cancelled' DELETE bez WHERE usuwa wszystkie wiersze z tabeli. Sformatowany kod czyni obecność lub brak WHERE natychmiast widocznym. Niektóre zespoły przyjmują konwencję zawsze pisania zapytań DELETE najpierw jako zapytań SELECT (zastępując DELETE FROM z SELECT * FROM), by zweryfikować, które wiersze będą dotknięte, następnie konwertując z powrotem na DELETE. Funkcje okna to jedne z najbardziej złożonych konstrukcji SQL do formatowania. Klauzula OVER z PARTITION BY i ORDER BY powinna być we własnych wciętych liniach, gdy są długie: SELECT customer_id , order_date , amount , SUM(amount) OVER ( PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders Dla krótkich specyfikacji okna utrzymanie ich w jednej linii jest akceptowalne: ROW_NUMBER() OVER (ORDER BY id) AS row_num. Celem jest czytelność przy długości i złożoności rzeczywistego wyrażenia. Nazwane definicje okna (WINDOW w AS (PARTITION BY customer_id ORDER BY order_date)) po których następuje OVER w redukują powtórzenie, gdy wiele kolumn używa tej samej specyfikacji okna. Kapitalizacja słów kluczowych to wybór stylu z silnymi opiniami po obu stronach. Słowa kluczowe WIELKIMI LITERAMI (SELECT, FROM, WHERE) wizualnie odróżniają składnię SQL od nazw tabel i kolumn. Słowa kluczowe małymi literami wtapiają się, ale są łatwiejsze do wpisania. Najważniejsza jest spójność. Wybierz jedną konwencję i egzekwuj ją w całym zespole. Wiele organizacji używa wielkich liter dla słów kluczowych i małych dla identyfikatorów. Niektóre nowoczesne przewodniki stylu preferują wszystkie małe litery dla wszystkiego, argumentując, że podświetlanie składni w edytorach już odróżnia słowa kluczowe od identyfikatorów. Trzecie podejście kapitalizuje tylko główne słowa kluczowe klauzul (SELECT, FROM, WHERE) i pozostawia nazwy funkcji i drobne słowa kluczowe małymi literami. Aliasy tabel powinny być znaczące. Używanie jednoliterowych aliasów (a, b, c) oszczędza wpisywanie, ale czyni zapytania trudniejszymi do czytania, zwłaszcza przy wielu złączeniach. Krótkie skróty wyprowadzone z nazwy tabeli są lepsze: customers AS c, orders AS o, order_items AS oi. W złożonych zapytaniach z wieloma tabelami dłuższe aliasy poprawiają jasność: customers AS cust, order_items AS items. Zawsze używaj słowa kluczowego AS dla aliasów, by odróżnić je od literówek lub zapomnianych przecinków. Nigdy nie używaj słów zastrzeżonych jako aliasów. Szerokość wcięcia powinna być spójna. Dwie spacje i cztery spacje to oba powszechne wybory. Tabulatory vs spacje to preferencja, ale spacje produkują bardziej spójne wyrównanie między edytorami i narzędziami. Narzędzie formatujące SQL pozwala Ci skonfigurować szerokość wcięcia, by pasowała do standardu Twojego zespołu. Niezależnie od tego, jaką szerokość wybierzesz, używaj jej jednolicie dla wszystkich poziomów wcięcia: treść klauzuli, zagnieżdżanie podzapytań, ciała wyrażeń CASE i definicje CTE. Formatowanie komentarzy w SQL używa -- dla komentarzy jednoliniowych i /* */ dla komentarzy wieloliniowych. Umieszczaj komentarze powyżej klauzuli lub wyrażenia, które opisują, nie inline na końcu długiej linii, gdzie mogą zostać przeoczone. Dla złożonej logiki biznesowej w klauzulach WHERE komentarz wyjaśniający, dlaczego warunek istnieje, jest wartościowy: -- Wyklucz konta testowe utworzone przez zespół QA przed warunkiem filtru. Komentarze, które powtarzają SQL (-- Join customers table), dodają szum bez wartości. Dobre komentarze wyjaśniają intencję, nie mechanikę. Formatowanie i wydajność zapytań nie są bezpośrednio powiązane. Silnik bazy danych parsuje i optymalizuje zapytanie niezależnie od białych znaków i łamań linii. Jednak dobrze sformatowane zapytania są łatwiejsze do optymalizacji, bo widzisz strukturę jasno. Słabo sformatowane zapytanie z problemem wydajności ukrywa problem w ścianie tekstu. To samo zapytanie, prawidłowo sformatowane, ujawnia problematyczne podzapytanie, brakujący warunek złączenia, niepotrzebny DISTINCT lub niesargowalną klauzulę WHERE na pierwszy rzut oka. Formatowanie to narzędzie debugowania i optymalizacji. Kontrola wersji i formatowanie SQL wchodzą w interakcję w ważny sposób. Reformatchowanie całego zapytania w pojedynczym commicie produkuje diff, który dotyka każdej linii, czyniąc niemożliwym zobaczenie, co faktycznie się zmieniło. Przyjmując formater dla istniejącej bazy kodu, wykonaj formatowanie w dedykowanym commicie z jasną wiadomością jak "Apply SQL formatting standard". Kolejne zmiany produkują wtedy czyste, znaczące diffy. Wiodące przecinki są popularne częściowo dlatego, że dodanie nowej kolumny do SELECT produkuje jednoliniowy diff (nowa linia), podczas gdy końcowe przecinki wymagają modyfikacji poprzedniej linii, by dodać przecinek, tworząc dwuliniowy diff. Różnice dialektowe wpływają na wybory formatowania. PostgreSQL, MySQL, SQL Server, Oracle, SQLite i BigQuery każda mają wariacje składni. PostgreSQL używa rzutowania podwójnego dwukropka (value::type) i ciągów cytowane dolarem. MySQL używa cytowania backtick dla identyfikatorów i LIMIT z OFFSET. SQL Server używa cytowania nawiasami kwadratowymi, TOP zamiast LIMIT i CROSS APPLY zamiast LATERAL JOIN. Oracle używa ROWNUM, CONNECT BY dla zapytań hierarchicznych i różnych funkcji daty. BigQuery używa cytowania backtick dla nazw tabel kwalifikowanych projektem. Formater powinien obsługiwać dialekt, którego używa Twój zespół. Narzędzie formatujące SQL obsługuje standardową składnię SQL, która jest kompatybilna ze wszystkimi głównymi dialektami. Przyjęcie przez zespół standardów formatowania SQL wymaga współdzielonej konfiguracji i idealnie zautomatyzowanego egzekwowania. Uwzględnij reguły formatowania SQL w swoim przewodniku stylu kodu. Używaj hooków pre-commit lub kontroli CI, by weryfikować formatowanie na plikach SQL. Zdefiniuj standard w pliku konfiguracyjnym narzędzia (jak .sql-formatter.json), który jest commitowany do repozytorium. Początkowy koszt uzgodnienia standardu jest zwracany przez każde przeglądanie kodu, które już nie obejmuje drobnych poprawek formatowania, i każdą sesję debugowania, która zaczyna się od czytelnego kodu zamiast ćwiczenia reformatchowania. SQL w kodzie aplikacji (osadzony w Pythonie, JavaScript, Java lub innych językach) stawia dodatkowe wyzwania formatowania. Surowy ciąg SQL wewnątrz funkcji Python lub literału szablonowego JavaScript podlega zarówno regułom formatowania języka hosta, jak i regułom formatowania SQL. Wieloliniowe literały ciągów (potrójne cudzysłowy Python, backticks JavaScript) pozwalają Ci utrzymać formatowanie SQL w kodzie aplikacji. Oddziel ciąg SQL od logiki aplikacji: przypisz zapytanie do nazwanej stałej (const FIND_ACTIVE_USERS = ...) i odwołuj się do niego, gdzie potrzebne. Dla dużych kolekcji zapytań przenieś SQL do osobnych plików .sql i załaduj je w czasie wykonania. SQL generowany przez ORM często potrzebuje formatowania do debugowania. Gdy Twoje zapytanie Django, SQLAlchemy, ActiveRecord lub Prisma produkuje nieoczekiwane wyniki, oglądanie wygenerowanego SQL pomaga zdiagnozować problem. Większość ORM zapewnia sposób na wyprowadzenie surowego SQL (query.toString() w Knex, str(query) w SQLAlchemy, .explain() w Django). Wklej wygenerowany SQL do formatera, by zrozumieć jego strukturę. SQL generowany przez ORM jest zazwyczaj gęsty i trudny do czytania, bo nigdy nie był przeznaczony dla ludzi. Sformatowane wyjście czyni złączenia, warunki i podzapytania widocznymi. Procedury składowane i funkcje wymagają dyscypliny formatowania ponad indywidualnymi zapytaniami. Każda procedura zawiera wiele instrukcji SQL, deklaracje zmiennych, przepływ sterowania (IF/ELSE, WHILE, FOR) i obsługę wyjątków (TRY/CATCH, BEGIN/EXCEPTION). Formatuj każdą instrukcję SQL wewnątrz procedury używając standardowych reguł formatowania zapytań. Wcinaj ciała przepływu sterowania jeden poziom od ich słów kluczowych. Umieszczaj BEGIN i END we własnych liniach. Dodawaj puste linie między logicznymi sekcjami wewnątrz procedury. Dobrze sformatowane procedury składowane są dramatycznie łatwiejsze do debugowania niż gęste, niesformatowane. Pliki migracji korzystają z formatowania SQL, bo są przeglądane w pull requestach i reprezentują trwałe zmiany schematu bazy danych. Instrukcja CREATE TABLE ze sformatowanymi definicjami kolumn jest łatwa do przeglądu pod kątem poprawnych typów danych, ograniczeń, dopuszczalności null i wartości domyślnych. ALTER TABLE z wieloma instrukcjami ADD COLUMN powinna wylistować każdą kolumnę we własnej linii. Formatowanie czyni przegląd migracji szybszym i redukuje szansę wysłania migracji z niepoprawnymi typami kolumn lub brakującymi ograniczeniami. Zapytania analizy wydajności (EXPLAIN, EXPLAIN ANALYZE) produkują wyjście, które jest łatwiejsze do skorelowania z zapytaniem, gdy samo zapytanie jest sformatowane. Jeśli wkleisz jednoliniowe zapytanie do EXPLAIN ANALYZE, wyjście odnosi się do operacji na specyficznych komponentach zapytania, które są trudne do zlokalizowania w jednoliniowym ciągu. To samo zapytanie, prawidłowo sformatowane, pozwala Ci dopasować każdą linię planu wykonania do odpowiedniej klauzuli w zapytaniu. Ta korelacja jest istotna dla identyfikacji, które złączenie lub podzapytanie powoduje problemy wydajnościowe. Dynamiczne generowanie SQL w kodzie aplikacji powinno produkować sformatowane wyjście. Gdy budujesz zapytania programowo (konstruując ciągi SQL w oparciu o wejście użytkownika lub konfigurację), dodawaj nowe linie i wcięcia do wygenerowanego zapytania. To kosztuje nic w czasie wykonania, ale czyni logowanie i debugowanie dramatycznie łatwiejszym. Gdy wygenerowane zapytanie powoduje błąd lub działa słabo, możesz przeczytać sformatowany SQL w logu i natychmiast zrozumieć strukturę. Konkatenacja wszystkiego w jedną linię oszczędza kilka znaków, ale tworzy bóle głowy debugowania. Listy kontrolne przeglądu kodu SQL korzystają ze standardów formatowania. Recenzent sprawdzający sformatowany SQL może systematycznie zweryfikować: poprawne typy złączeń dla każdej relacji tabeli, warunki klauzuli WHERE pasujące do wymogu biznesowego, GROUP BY uwzględniający wszystkie niezagregowane kolumny, ORDER BY odzwierciedlający oczekiwane sortowanie, odpowiednie użycie LEFT JOIN vs INNER JOIN (LEFT JOIN, gdzie INNER wystarczyłoby, wskazuje albo na błąd, albo na niepotrzebną ostrożność) i brak powszechnych antywzorców jak SELECT * w kodzie produkcyjnym, niejawne złączenia krzyżowe i skorelowane podzapytania, które mogłyby być przepisane jako złączenia. Formatowanie dużych zapytań legacy to jedno z najbardziej wartościowych zastosowań formatera SQL. Korporacyjne bazy danych akumulują zapytania przez lata lub dekady. Zapytania napisane przez deweloperów, którzy dawno odeszli z firmy, modyfikowane wielokrotnie i nigdy niesformatowane stają się ścianami tekstu, których nikt nie odważy się dotknąć. Przepuszczenie tych zapytań przez formater to pierwszy krok do uczynienia ich utrzymywalnymi. Sformatuj zapytanie, commituj zmianę formatowania osobno, następnie rozpocznij rzeczywistą pracę modyfikacyjną z czytelnym punktem startowym. Narzędzie formatujące SQL bierze dowolne ważne zapytanie SQL, parsuje jego strukturę i wyprowadza spójnie sformatowany SQL następujący konfigurowalne reguły dla wcięcia, wielkości liter słów kluczowych i umiejscowienia klauzul. Wklej swoje zapytanie, kliknij formatuj i skopiuj wynik. Używaj go do formatowania zapytań przed commitowaniem, czyszczenia legacy SQL do przeglądu, standaryzacji zapytań otrzymanych od kolegów lub wygenerowanych przez narzędzia ORM i przygotowywania SQL do dokumentacji lub prezentacji.
Czeste pytania
Które dialekty SQL są obsługiwane?
Formater obsługuje standardową składnię SQL, w tym SELECT, JOIN, WHERE, GROUP BY i inne popularne klauzule.
Czy modyfikuje logikę mojego zapytania?
Nie, formater zmienia tylko białe znaki i wielkość liter. Logika zapytania pozostaje dokładnie ta sama.
