SQL フォーマッター

PostgreSQL、MySQL、SQLite などの SQL をフォーマット・整形します。

このツールについて

ログにある長い 1 行のクエリでも、貼り付ければ 1 行に 1 句ずつ整形されます。SQL の方言、キーワードの大文字・小文字、インデントを選べます。

使い方

  1. ログや ORM のデバッグ出力からコピーした長い 1 行のクエリなどを貼り付けます。
  2. キーワードや構文が正しく認識されるよう、データベースの方言を選びます。
  3. キーワードの大文字・小文字（UPPER、lower、入力どおり）とインデントを選ぶか、「1 行」でコンパクトにまとめます。
  4. フォーマットされたクエリをコピーします。

よくある質問

どのデータベースに対応していますか？
標準 SQL、PostgreSQL、MySQL、MariaDB、SQLite、SQL Server（T-SQL）、Oracle PL/SQL、BigQuery、Snowflake、Redshift、DuckDB、ClickHouse、Spark SQL、Trino/Presto。
フォーマットするとクエリの動作が変わりますか？
いいえ。変わるのは空白と、選んだ場合はキーワードの大文字・小文字だけです。識別子、文字列リテラル、クエリのロジックはそのまま保たれます。
複数のステートメントを一度にフォーマットできますか？
はい。セミコロンで区切れば、各ステートメントが個別にフォーマットされ、間に空行が入ります。
クエリはどこかに送信されますか？
いいえ。フォーマットはブラウザー内で行われるため、本番環境のテーブル名やデータを含むクエリが手元のマシンの外に出ることはありません。
SQL フォーマッターはクエリのエラーをチェックしますか？
いいえ。トークンを配置するだけで、データベースやスキーマに対してクエリを検証しないため、select a, from t もそのままフォーマットされます。エラーが表示されるのは、選択した方言でテキストをまったく読み込めない場合だけです。本当の誤りを見つけるには、クエリを実行するか EXPLAIN してください。
-- コメントを含むクエリに「1 行」を使っても安全ですか？
必ずしも安全ではありません。-- コメントは行末まで続くため、クエリを 1 行にまとめると、コメント以降がすべてコメントの一部になってしまいます。「1 行」を使う前に、-- コメントを削除するか /* … */ に書き換えてください。ブロックコメントなら 1 行にしても安全です。
dbt モデルなどテンプレート化された SQL をフォーマットできますか？
直接はできません。二重の波かっこで書くテンプレートタグや、if や for などの制御ブロックは SQL ではないため、フォーマッターは最初のタグでパースエラーになって止まります。dbt compile などで先にモデルをコンパイルし、生成された SQL をフォーマットしてください。

SQL フォーマッターとは？

SQL フォーマッターは、構造が見えるようにクエリを書き直します。SELECT、FROM、JOIN、WHERE、GROUP BY、ORDER BY などの各句がそれぞれ新しい行から始まり、その下の列や条件はインデントされ、かっこはインデントされたブロックを開きます。select id, email from users where active = true and (plan = 3 or trial = true) のような 1 行のクエリが十数行の短い行になり、どの条件がまとまっているかがわかります。

キーワードの大文字・小文字は慣習の問題です。「UPPER」はキーワードをテーブル名や列名から目立たせる伝統的なスタイルで、「小文字」は新しいスタイルガイドやアナリティクスチームでよく使われ、「入力どおり」はレイアウトだけを直したいときにキーワードをそのままにします。インデントはスペース 2 個か 4 個を選ぶか、「1 行」でコード内の文字列やログ検索用にクエリを 1 行にまとめます。SQL のコメントは出力にも残ります。

SQL がフォーマットできないのはなぜ？「Parse error: Unexpected」の直し方

SQL フォーマッターは選択した方言の規則でクエリを読み込むため、別のデータベースの構文があると「Parse error: Unexpected … at line 1 column 8」のようなエラーになります。`order` のようなバッククォートで囲んだ識別子は MySQL、MariaDB、BigQuery、Spark の構文で、PostgreSQL や SQL Server では失敗します。[order] のような角かっこは SQL Server のもので、MySQL では失敗します。クエリが書かれた方言を選べば、たいていエラーは消えます。

プレースホルダーも方言によって異なります。JDBC や MySQL ドライバーの ? は標準 SQL、MySQL、PostgreSQL、SQLite で使え、$1 は PostgreSQL で使えます。SQL Server は @id のような名前付きパラメーターを想定するため、そこで ? を使うとフォーマッターが止まります。dbt などの Jinja ベースのツールのテンプレートタグはそもそも SQL ではないため、最初のタグでパースエラーになります。代わりにコンパイル後のクエリをフォーマットしてください。

読みやすいクエリのための SQL スタイルのベストプラクティス

フォーマットで直るのはレイアウトですが、いくつかの習慣でクエリはさらにレビューしやすくなります。FROM にカンマでテーブルを並べる代わりに明示的な JOIN … ON を書き、users には u、orders には o のように短く意味のある別名を付け、SELECT * ではなく必要な列を指定しましょう。WITH … AS で書く共通テーブル式（CTE）を使えば、長いクエリを上から下へ読める名前付きのステップに分割できます。

リポジトリごとに SQL のフォーマット設定を 1 つに揃えましょう。方言、キーワードの大文字・小文字、インデントを統一すれば、クエリを再フォーマットしてもコードレビューにノイズが加わりません。長いクエリの 2 つのバージョンを比較するには、両方をここで同じ設定でフォーマットしてからテキスト差分に貼り付けてください。この手順を省くと、クエリ自体は同じでも、改行位置が動いただけで差分として表示されます。

うまく動かない、または結果がおかしいですか？ このツールの問題を報告

フォーマットのその他のツール

よく一緒に使われるツール