SQL フォーマッタ

SQL フォーマッターとは？#

SQL フォーマッターは、エンジン向けに書かれたクエリ——しばしば 1 行に詰め込まれたものや、ログからランダムなインデントで貼り付けられたもの——を、人間向けに書かれたクエリに変えます。キーワードは独自の行に、列は揃い、サブクエリは 1 レベル段が下がり、5 つの AND 条件を持つ WHERE 句がテキストの壁でなくなります。逆の操作である圧縮は、クエリが設定ファイルや API パラメータを通って移動する必要があるとき、これらの空白をすべて 1 行に折りたたみます。

SQL の整形が面倒なのは、すべてのデータベースが独自の方言を持つからです。RETURNING を持つ Postgres クエリ、バッククォートで囲まれた識別子を持つ MySQL クエリ、TOP (n) を持つ SQL Server クエリ、構造体と配列リテラルを持つ BigQuery クエリはすべて異なって見え、普遍的な SQL が 1 つあると見せかけるフォーマッターはエッジケースを微妙に間違えます。このページは sql-formatter に明示的な方言選択を組み合わせてこれに対処します: 標準 SQL、MySQL、MariaDB、PostgreSQL、SQLite、T-SQL、PL/SQL、BigQuery、Redshift、Snowflake、DB2、Trino です。データベースが実際に話すものを選べば、フォーマッターはそれに従って解析します。

使い方#

1. 左のSQLペインにクエリを貼り付けるか、サンプルをクリックして短い例を読み込みます。
2. ツールバーで方言を選びます——データベースの方言です。既定の sql は安全な汎用フレーバーで、クエリが方言固有の構文を使うときに postgresql、mysql、tsql などに切り替えます。
3. インデントを選びます: 2、4、タブ。長い列リストを読みやすく保つため、SQL では 4 スペースが一般的です。
4. アクションをクリックします:
   • 整形 — 再インデントし、クエリを論理的な行に分割し、既定でキーワードを大文字にして SELECT、FROM、WHERE が識別子から際立ちます。
   • 圧縮 — -- 行コメントと /* */ ブロックコメントを削除し、すべての空白の連続を単一スペースに折りたたみます。改行はスペースになります。文は改行ではなくセミコロンで終わるため、SQL では安全です。
5. 出力ペインで結果を読みます。コピーで取り出し、クリアで両ペインをリセットします。

主な特徴#

• 12 の方言。 MySQL、MariaDB、PostgreSQL、SQLite、T-SQL、PL/SQL、BigQuery、Redshift、Snowflake、DB2、Trino に加え、汎用の標準 SQL。フォーマッターの文法が合わせて変わるため、方言固有のキーワードが正しく配置されます。
• キーワードのケース。 整形は既定でキーワードを大文字にし（select は SELECT に）、識別子には触れません。これは純粋に装飾的で、クエリが何をするかを変えることはありません。
• 安全な圧縮。 空白は単一スペースに折りたたまれます。SQL はセミコロン終端であるため、改行 sensitive な言語で起こるように、行を結合して 2 つの文を融合させることはありません。
• 圧縮時のコメント削除。 圧縮時に -- と /* */ の両方のコメントが削除され、ペイロードが引き締まります。
• 2 ペイン、コピーレディ、完全にクライアントサイド。 フォーマッターはブラウザ内で走り、クエリはどこにも送信されません。

実例#

コメント、結合、GROUP BY を伴い、1 行にダンプされたレポートクエリ:

入力:

select u.id,u.name,count(o.id) as orders from users u join orders o on o.user_id=u.id where u.status='active' and o.created_at >= '2026-01-01' group by u.id,u.name order by orders desc

方言を postgresql にし、2 スペースで整形をクリック:

SELECT
  u.id,
  u.name,
  count(o.id) AS orders
FROM
  users u
  JOIN orders o ON o.user_id = u.id
WHERE
  u.status = 'active'
  AND o.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.name
ORDER BY
  orders DESC

すべての句が独自の行を持ち、結合条件が見え、2 つの WHERE 述語が分割されたため、日付フィルタが > ではなく >= であることがひと目で分かります。キーワードのケースは大文字になり、列名は書かれた通りに保たれました。同じ入力で圧縮をクリックすると、設定ファイルや ?query= パラメータに貼る準備のできた 1 行形式が戻ります:

select u.id,u.name,count(o.id) as orders from users u join orders o on o.user_id=u.id where u.status='active' and o.created_at >= '2026-01-01' group by u.id,u.name order by orders desc

よくある質問#

どの方言を選ぶべきですか？#

データベースに合わせてください。不確かなら、汎用の sql が妥当な出発点で、一般的な句を正しく扱います。クエリが汎用文法が想定しない構文——RETURNING（Postgres）、バッククォート識別子（MySQL）、TOP (n)（T-SQL）、構造体/配列リテラル（BigQuery）——を使うときに特定の方言に切り替えてください。違う方言を選んでもたいていは整形されますが、風変わりなキーワードを間違った場所に置くかもしれません。

整形はキーワードを大文字にするのに列名にはしないのはなぜですか？#

キーワードの大文字化は意味を変えない可読性の慣習——SELECT と select はエンジンにとって同一——である一方で、識別子は大文字小文字を区別しうるからです（Postgres はクォートなしの識別子を小文字に畳み込み、MySQL は一部のプラットフォームで大文字小文字を区別します）。識別子に触れないことが安全な既定です。小文字のキーワードを好むなら、クエリを整形してから手動でパスをかけてください。

圧縮は複数文のスクリプトを保ちますか？#

改行を含むすべての空白の連続を単一スペースに折りたたみますが、セミコロンはあった場所を正確に保ちます。だから SELECT 1; SELECT 2; は ; で区切られた 2 つの文のままです。とはいえ、多くの文を持つ長いマイグレーションスクリプトには、1 行の圧縮形式は読みにくく、デバッグしにくいため——圧縮は単一クエリや短いバッチに向いています。

クエリはどこかにアップロードされますか？#

いいえ。フォーマッターはページに同梱され、ブラウザ内でローカルに走ります。SQL に関するもの——テーブル名も、リテラルも——タブから外に出ることはありません。