Formater SQL
Formatuj i upiększaj SQL dla PostgreSQL, MySQL, SQLite i innych.
O tym narzędziu
Wklej zapytanie, nawet długi jednolinijkowiec z logu, i otrzymaj je rozłożone po jednej klauzuli w linii. Wybierz dialekt SQL, wielkość liter słów kluczowych i wcięcia.
Jak z tego korzystać
- Wklej zapytanie, np. długi jednolinijkowiec skopiowany z logu lub z wyjścia debugowania ORM.
- Wybierz dialekt bazy danych, aby jego słowa kluczowe i składnia były rozpoznawane.
- Wybierz wielkość liter słów kluczowych (WIELKIE, małe lub jak wpisano) i wcięcie albo Jedna linia, aby je skompaktować.
- Skopiuj sformatowane zapytanie.
Pytania
- Które bazy danych są obsługiwane?
- Standardowy SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, DuckDB, ClickHouse, Spark SQL i Trino/Presto.
- Czy formatowanie zmienia działanie zapytania?
- Nie. Zmieniają się tylko białe znaki i, jeśli tak wybierzesz, wielkość liter słów kluczowych. Identyfikatory, literały tekstowe i logika zapytania pozostają dokładnie takie same.
- Czy mogę sformatować kilka instrukcji naraz?
- Tak. Rozdziel je średnikami, a każda instrukcja zostanie sformatowana osobno, z pustą linią pomiędzy.
- Czy moje zapytanie jest gdzieś wysyłane?
- Nie. Formatowanie odbywa się w Twojej przeglądarce, więc zapytania z nazwami tabel czy danymi z produkcji nigdy nie opuszczają Twojego komputera.
- Czy formater SQL sprawdza zapytanie pod kątem błędów?
- Nie. Układa tokeny, ale nie waliduje zapytania względem bazy danych ani schematu, więc select a, from t zostanie sformatowane bez zastrzeżeń. Błędy pojawiają się tylko wtedy, gdy tekstu w ogóle nie da się odczytać w wybranym dialekcie. Uruchom zapytanie albo jego EXPLAIN, aby znaleźć prawdziwe błędy.
- Czy Jedna linia jest bezpieczna dla zapytań z komentarzami --?
- Nie zawsze. Komentarz -- trwa do końca linii, więc gdy zapytanie zostanie zwinięte do jednej linii, wszystko po komentarzu stanie się jego częścią. Usuń komentarze -- albo przepisz je jako /* … */, zanim użyjesz opcji Jedna linia. Komentarze blokowe są bezpieczne w jednej linii.
- Czy mogę formatować modele dbt lub inny SQL z szablonami?
- Nie bezpośrednio. Tagi szablonów w podwójnych nawiasach klamrowych oraz bloki sterujące, takie jak if i for, nie są SQL-em, więc formater zatrzymuje się z błędem parsowania przy pierwszym tagu. Najpierw skompiluj model, np. poleceniem dbt compile, i sformatuj wygenerowany SQL.
Co robi formater SQL?
Formater SQL przepisuje zapytanie tak, by jego struktura była widoczna. Każda klauzula, np. SELECT, FROM, JOIN, WHERE, GROUP BY i ORDER BY, zaczyna się w nowej linii, kolumny i warunki pod nią są wcięte, a nawiasy otwierają wcięty blok. Jednolinijkowiec taki jak select id, email from users where active = true and (plan = 3 or trial = true) zamienia się w kilkanaście krótkich linii, w których widać, które warunki należą do siebie.
Wielkość liter słów kluczowych to kwestia konwencji. WIELKIE to tradycyjny styl, który odróżnia słowa kluczowe od nazw tabel i kolumn, małe są popularne w nowszych przewodnikach stylu i zespołach analitycznych, a Jak wpisano zostawia słowa kluczowe bez zmian, gdy chcesz poprawić tylko układ. Wybierz wcięcie z 2 lub 4 spacji albo Jedna linia, aby zwinąć zapytanie do ciągu w kodzie lub do wyszukiwania w logach. Komentarze SQL są zachowywane w wyniku.
Dlaczego SQL się nie formatuje? Jak naprawić „Parse error: Unexpected”
Formater SQL czyta zapytanie według reguł wybranego dialektu, więc składnia z innej bazy danych powoduje błąd w rodzaju „Parse error: Unexpected … at line 1 column 8”. Identyfikatory w backtickach, takie jak `order`, to składnia MySQL, MariaDB, BigQuery i Spark, która nie przejdzie w PostgreSQL ani SQL Server. Nawiasy kwadratowe, jak w [order], należą do SQL Server i nie przejdą w MySQL. Wybierz dialekt, dla którego napisano zapytanie, a błąd zwykle zniknie.
Placeholdery też zależą od dialektu. ? z JDBC albo sterownika MySQL działa w dialektach Standardowy SQL, MySQL, PostgreSQL i SQLite, $1 działa w PostgreSQL, a SQL Server oczekuje parametrów nazwanych, takich jak @id, więc ? zatrzymuje tam formater. Tagi szablonów z dbt i innych narzędzi opartych na Jinja w ogóle nie są SQL-em i powodują błąd parsowania przy pierwszym tagu. Sformatuj zamiast tego skompilowane zapytanie.
Dobre praktyki stylu SQL: jak pisać czytelne zapytania
Formatowanie poprawia układ, a kilka nawyków ułatwia przeglądanie zapytań. Pisz jawne JOIN … ON zamiast wymieniać tabele po przecinku w FROM, nadawaj tabelom krótkie, znaczące aliasy, np. u dla users i o dla orders, i wymieniaj potrzebne kolumny zamiast SELECT *. Wyrażenia CTE zapisane przez WITH … AS dzielą długie zapytanie na nazwane kroki, które czyta się od góry do dołu.
Trzymaj jedną konfigurację formatowania SQL na repozytorium: ten sam dialekt, wielkość liter słów kluczowych i wcięcia, aby przeformatowanie zapytania nigdy nie dodawało szumu w code review. Aby porównać dwie wersje długiego zapytania, sformatuj obie tutaj z identycznymi ustawieniami, a potem wklej je do narzędzia Porównywarka tekstów. Bez tego kroku przesunięty podział linii pokaże się jako różnica, choć samo zapytanie jest takie samo.
Coś nie działa albo wynik wygląda na błędny? Zgłoś problem z tym narzędziem