すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
左に SQL 文を貼り付けると、右パネルに 1 句 1 行・JOIN を縦に揃え・リストを改行に分けた読みやすい形で出力されます。Dialect セレクタでターゲット DB(PostgreSQL・MySQL・Snowflake・T-SQL・BigQuery・SQLite ほか計 14 種)に合わせてください。方言の選択は、予約語の認識、引用識別子の扱い、`QUALIFY`・`RETURNING`・`EXCEPT` のような方言固有の句の解釈に影響します。Keyword case は UPPER(SQL コミュニティの慣例)、lower、preserve から選べ、tab width は 1〜8 スペースで調整できます。
フォーマッターは文を句のツリーへパースしてから再出力します。正規表現ベースの prettyprinter ではないため、JOIN にまたがるカンマやインライン CASE 式は単に折り返されるのではなく、構造を保ったまま整形されます。スキーマに対するクエリの検証や、クエリの実行は行いません。すべての処理は `sql-formatter` ライブラリを使ってブラウザ内で完結するため、内部テーブル名や本番データを含むクエリもマシン外には出ません。
select id, name, email from users where created_at > '2024-01-01' and status in ('active','pending') order by created_at desc limit 100SELECT
id,
name,
email
FROM
users
WHERE
created_at > '2024-01-01'
AND status IN ('active', 'pending')
ORDER BY
created_at DESC
LIMIT
100各句が独立した見出し行になり、列リストは 1 行 1 列に分割されます。列を追加・並べ替えた際の diff が綺麗で、一行クエリに比べて PR で変更点を捉えやすくなります。
with active_users as (select id from users where status='active') select o.id, o.total, u.email from orders o join active_users au on o.user_id=au.id join users u on u.id=au.id where o.created_at >= now() - interval '7 days' returning *
WITH active_users AS (
SELECT
id
FROM
users
WHERE
status = 'active'
)
SELECT
o.id,
o.total,
u.email
FROM
orders o
JOIN active_users au ON o.user_id = au.id
JOIN users u ON u.id = au.id
WHERE
o.created_at >= now() - INTERVAL '7 days'
RETURNING
*CTE 本体はネストされ、JOIN は FROM の下に縦に揃いつつ条件をインラインで表示します。`RETURNING` や `INTERVAL '7 days'` 構文があるため PostgreSQL 方言を選ぶ必要があります。Standard SQL モードでは認識できません。
SELECT * FROM events QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY ts DESC) = 1
(parses cleanly with Snowflake or BigQuery dialect; loses structure with PostgreSQL since it has no QUALIFY clause)
`QUALIFY` はウィンドウ関数の後で行を絞り込む句で、Snowflake・BigQuery・Databricks・Teradata に存在しますが PostgreSQL・MySQL・SQLite にはありません。該当する方言を選ばないと、フォーマッターは `QUALIFY` を未知の識別子として扱い、構造の少ない出力に落ちます。
いいえ。構文を再出力するだけです。パーサは字句が認識可能な形であるかは確認しますが、データベースに接続することも、テーブルを参照することも、列の存在を確認することもありません。本ツールで綺麗に整形されたクエリでも、テーブル名のタイポ、権限不足、スキーマの変化などで実行時に失敗することはあります。
SQL コミュニティで長く続く慣例です。予約語を大文字にすると、構文ハイライトがないターミナルや grep 出力でも、句の構造が小文字の識別子と対比されて見えやすくなります。Mode・Holistics・SQL Style Guide のガイドラインも一様に推奨しています。チームが Python 風の小文字を好むなら `lower`、入力を変更したくないなら `preserve` に切り替えてください。
クエリの実行先データベースに合わせてください。不明な場合は PostgreSQL が最も無難な選択です。Standard SQL の広い上位互換(ウィンドウ関数・CTE・`RETURNING`・JSON 演算子など)を受け付け、他のエンジン向けに書かれたクエリの多くも問題なくパースされます。BigQuery・Snowflake・T-SQL を使う場合は、方言固有の句(`QUALIFY`・差集合の `EXCEPT`・`TOP n` など)が対応するパーサを必要とするため、明示的にそれらを選んでください。
ほとんどのコードレビューツール、diff ビューア、共有環境がタブを予測不能に表示するため(あるエディタでは 4 スペース、別のエディタでは 8 スペースなど)、本ツールはスペースを強制します。スタイルガイドがタブを必須とする場合は、出力を `expand -t1 | sed 's/ /\t/g'` で後処理するか、エディタの一括置換でタブに戻してください。実運用の SQL ファイルはほぼ例外なくスペースを使っています。
はい。行コメント(`--`)とブロックコメント(`/* … */`)はどちらも元の位置に保持されます。パース・再出力の往復で消えないので、本番クエリにそのままフォーマッターをかけてもインラインドキュメントは失われません。`/*+ INDEX(t i_t_a) */`(Oracle)や `/*! STRAIGHT_JOIN */`(MySQL)などのヒント構文も通常のコメントブロックとして保たれます。
エディタ連携には CLI を使ってください — `pg_format`、`sqlfluff format`、または `sql-formatter` パッケージ自体を Prettier プラグインで呼ぶ方法があります。本ウェブツールは単発の貼り付け用です(同僚のアドホッククエリ、スクリーンショットから書き写したクエリ、チケットを切る前の確認など、10 行整形するためにプロジェクトを開くのが過剰な場合)。両者は同じフォーマットライブラリを共有するので出力結果に齟齬はありません。
SQL は 1986 年に最初に標準化され(ANSI SQL-86)、現行版は SQL:2023 ですが、主要エンジンはどれも標準の上に独自の方言を載せています。差は表層的ではありません。Snowflake で動くクエリが PostgreSQL ではパースできない、というのは `QUALIFY`・`LATERAL FLATTEN`・`:` 変数置換などのせいです。`GO` セパレータや `DECLARE @x` を含む T-SQL バッチは MySQL からは意味を成しません。方言対応のフォーマッターは、選択された文法に対してクエリをパースし、標準にない構文も保持したまま再出力します。
フォーマットは近接する 3 つの分野のひとつです。**フォーマット** はクエリの意味を変えず、ホワイトスペースとケースのみを再構成します(本ツール)。**リント** はスタイルや正しさの匂いを検出します(`sqlfluff`・`sqlint`・Snowflake 向け `dbt` linter など)。修飾なしの `*`、未使用 CTE、暗黙の型変換などです。**静的解析** はもう一歩進み(`squawk`・`eversql`・`pganalyze` など)、クエリプランを読みインデックス不足やテーブルロックを伴う DDL を警告します。フォーマッターはコミットごとに安全に自動実行できます。リンタは pre-commit フック向き。アナライザは通常、実プランナに対して走らせます。
隣接する 3 つの SQL 記述慣行も覚えておくと役立ちます。**先頭カンマ**(`, column_a` を `column_a,` の代わりに置く)は行を追加する際の diff を綺麗にし、Mode・HashiCorp・いくつかのデータチームのスタイルガイドが採用しています。`sql-formatter` はこれを強制しません。**川型フォーマット**(river formatting)は句キーワード(`SELECT`・`FROM`・`WHERE` など)を共通の列に右揃えで配置します。古い Oracle 系の現場で見られ、保守が難しいため現代のガイドの多くは推奨しません。**スタック形式**は本ツールの既定で、句のヘッダを単独行に置き、内容を下にインデントします。チームがプルリクエストで最も速く読める形式を選び、フォーマッターに統制させるのが現実的です。