SQL フォーマッター

// SQL フォーマッターに関するよくある質問

どんな時に使うと便利？

(1) 他人から受け取った1行べた書きSQL の解読、(2) 自分で書いた複雑なJOINやサブクエリを見返す時、(3) コードレビュー前の下ごしらえ、(4) SQLをドキュメントに載せる時の整形、(5) BIツールの生SQLをきれいにする時、といった場面で使います。可読性が上がるとバグ発見も早くなります。

どのSQLデータベースに対応してる？

標準SQL準拠なので、**MySQL**・**PostgreSQL**・**SQLite**・**SQL Server**・**Oracle**・**MariaDB**・**Snowflake**・**BigQuery** など、主要なRDBMS/データウェアハウスのクエリで動作します。データベース固有の関数（例: PostgreSQLの `JSON_AGG`）や方言も文字として保持されるので、そのまま整形結果を実行できます。

文字列リテラルの中身は変更される？

いいえ、シングルクォート（`'...'`）で囲まれた文字列リテラルの中身は一切変更しません。「WHERE name = 'select'」のような、キーワードと同じ文字列が入っていても大文字化されないので、意図しない改変を心配せずに使えます。

複数のJOINをきれいに整形できる？

はい、`INNER JOIN`・`LEFT OUTER JOIN`・`RIGHT JOIN`・`CROSS JOIN` などすべての JOIN 種類に対応しています。各 JOIN を新しい行に配置し、ON 条件も適切にインデントします。3〜4つの JOIN が絡み合った複雑なクエリでも、テーブル関係が視覚的に把握できます。

サブクエリはどう整形されますか？

括弧で囲まれたサブクエリは自動的に一段深いインデントに配置されます。ネストが深い場合はさらに階層的にインデントされるので、「どこからどこまでがサブクエリか」が一目でわかります。相関サブクエリ・スカラーサブクエリ・EXISTS 内のサブクエリなど、あらゆる形に対応しています。

インデント幅は選べる？

2スペース・4スペースから選択できます。プロジェクトのコーディング規約に合わせてください。企業や PostgreSQL コミュニティでは4スペースが多く、GitHub・スタートアップ系では2スペースが人気です。

キーワードを小文字にしたい

「キーワード大文字化」オプションをOFFにすれば、元の大文字小文字を保ったまま整形します。小文字派の方（`select` `from` `where` で統一）の方針にも合わせられます。

大文字化と読みやすさ、どっちが優先？

読みやすさ優先派なら「キーワード大文字化 ON + 4スペース」が最も可読性が高くなります。コンパクト派なら「大文字化 ON + 2スペース」、キーボードから小文字入力の速さ重視なら「大文字化 OFF」が向いています。プロジェクトごとの慣習に合わせてください。

生成されたSQLはそのまま実行できる？

はい、整形は空白と改行の追加・キーワードの大文字化だけで、SQLの実行意味は変わりません。整形結果をコピーしてそのままDBクライアント（TablePlus・DBeaver・pgAdmin等）に貼り付けて実行できます。

入力したSQLは外部に送信されますか？

いいえ、すべての整形処理はブラウザ内で完結します。入力したSQL・整形結果は外部に送信されません。本番DBのSQL、機密テーブルを含むクエリ、社内システム用SQLなども安心して整形できます。