SQLフォーマッター
SQL クエリを瞬時に整形・美化。キーワードの大文字化、インデント設定、シンタックスハイライト。無料のオンライン SQL フォーマッタ。
主な機能
- キーワードの自動大文字化
- インデントの設定
- シンタックスハイライト
- 一般的な SQL 方言への対応
Guide
SQL フォーマッティングは、密集した読めないクエリを、読みやすく、レビューしやすく、デバッグしやすく、保守しやすい、構造化され一貫してインデントされたコードに変換します。単一行で書かれたとき完全に機能するクエリは、他の誰か（または3か月後のあなた）がそれが何をするかを理解する必要があるとき、保守の負担になります。一貫した SQL フォーマッティングは表面的ではありません。それはバグを減らし、コードレビューを高速化し、複雑なクエリを扱いやすくします。本ガイドでは、フォーマット規則、句の構造、異なるクエリタイプの一般的なパターン、フォーマッティングがクエリ最適化とどう相互作用するかを取り上げます。 SQL フォーマッティングの基盤の規則は1行に1句です。SELECT、FROM、WHERE、JOIN、ON、GROUP BY、HAVING、ORDER BY、LIMIT、INSERT INTO、VALUES、UPDATE、SET、DELETE FROM はそれぞれベースのインデントレベルで独自の行で始まります。この構造によりクエリが走査可能になります。どの列が選択され、どのテーブルが関与し、どの条件がデータをフィルターし、結果がどう並べ替えられるかが一目で分かります。このようにフォーマットされたクエリは、続く文ではなく構造化されたドキュメントのように読めます。 SELECT 句のフォーマッティングは各列を独自の行にリストし、SELECT キーワードから1レベルインデントします。先頭カンマ（行の終わりではなく各行の先頭のカンマ）は、個々の列のコメントアウトが容易で、バージョン管理できれいな diff を生むため一般的な慣習です。末尾カンマと先頭カンマの両方とも、選択がコードベース全体で一貫している限り許容されます。列のエイリアスは明確さのために（column_name alias という短縮形ではなく）AS キーワードを明示的に使うべきです（column_name AS alias）。列の式が長い（CASE 文や複数の引数を持つ関数呼び出し）場合、独自の行に置き、続きをインデントします。 FROM と JOIN 句は一貫した整列の恩恵を受けます。各 JOIN は FROM と同じインデントで独自の行を持ちます。ON 条件はその JOIN の下にインデントされます。多くの結合を持つクエリでは、この視覚構造によりテーブルの関係が明確になります： FROM orders o JOIN customers c ON c.customer_id = o.customer_id JOIN products p ON p.product_id = o.product_id LEFT JOIN shipping s ON s.order_id = o.order_id 結合タイプ（INNER JOIN、LEFT JOIN、RIGHT JOIN、CROSS JOIN、FULL OUTER JOIN）は意味を持ちます。各結合を視覚的に分離するフォーマッティングは、レビューアーが各関係に正しい結合タイプが使われていることを検証するのに役立ちます。INNER JOIN であるべき LEFT JOIN（またはその逆）は、フォーマットされたコードがより見つけやすくする一般的なバグです。 WHERE 句のフォーマッティングは各条件を独自の行に置き、行の先頭に AND または OR を置きます。WHERE の下に条件をインデントすることでフィルターの論理が見えるようになります： WHERE o.order_date >= '2026-01-01' AND o.status = 'completed' AND c.country = 'US' AND (p.category = 'electronics' OR p.category = 'appliances') 混在する AND と OR 演算子による複雑なブール論理はバグの一般的な原因です。明示的な括弧と明確なインデントによるフォーマッティングは論理的なグループ化を示します。フォーマットなしでは WHERE a = 1 AND b = 2 OR c = 3 は人間の読者には曖昧です（ただし SQL は OR の前に AND を評価するため (a = 1 AND b = 2) OR c = 3 を意味します）。括弧でフォーマットすれば意図が明確になります。混在する AND/OR には常に括弧を使い、優先順位を明示的にしましょう。 サブクエリはその括弧の内側に1レベルインデントされるべきです。各サブクエリはトップレベルのクエリと同じ規則を使ってフォーマットされます。相関サブクエリ（外側のクエリの列を参照するもの）は、外側のクエリとの関係がその動作を決定するため、明確にフォーマットすることが特に重要です： SELECT customer_name , total_spent FROM customers c WHERE total_spent > ( SELECT AVG(total_spent) FROM customers WHERE country = c.country ) インデントはサブクエリが WHERE 句の内側にネストされ、外側のクエリから c.country を参照することを示します。深くネストされたサブクエリ（3レベル以上）には、深いネストはフォーマッティングに関わらず追従が難しくなるため、代わりに CTE へのリファクタリングを検討しましょう。 WITH 句を使う共通テーブル式（CTE）は各 CTE を独立した名前付きブロックとしてフォーマットすべきです： WITH monthly_sales AS ( SELECT DATE_TRUNC('month', order_date) AS month , SUM(amount) AS total FROM orders GROUP BY DATE_TRUNC('month', order_date) ), monthly_avg AS ( SELECT AVG(total) AS avg_total FROM monthly_sales ) SELECT m.month , m.total , a.avg_total FROM monthly_sales m CROSS JOIN monthly_avg a WHERE m.total > a.avg_total CTE は複雑なクエリを読みやすくテスト可能なコンポーネントに分割するための最も強力な SQL 機能の一つです。各 CTE はその SELECT 文だけを実行することで独立してテストできます。適切なフォーマッティングは各 CTE の目的を見えるようにし、CTE 間のデータフローを追跡可能にします。CTE には説明的に名前を付けましょう：monthly_sales は cte1 より良いです。 GROUP BY と ORDER BY 句は複数の列を参照するとき SELECT と同じ複数行パターンに従います。各列を独自のインデントされた行にリストします。GROUP BY では、これによりすべての非集約 SELECT 列が含まれていることを確認しやすくなります（標準 SQL での要件で PostgreSQL で強制されますが、MySQL は既定で寛容です）。ORDER BY では、各並べ替え列をその方向（ASC または DESC）とともに別の行にリストすると並べ替えの優先順位が明確になります。（既定ですが）ASC を明示的に記述すると読みやすさが向上します。 HAVING 句のフォーマッティングは WHERE と同じ規則に従います。HAVING は集約の後にグループをフィルターし、その条件は1行に1条件でフォーマットされるべきです。一般的なフォーマットの間違いは HAVING 条件を WHERE 句に置く、またはその逆です。WHERE はグループ化の前に行をフィルターします。HAVING は集約の後にグループをフィルターします。正しい配置は正確性とパフォーマンスの両方に不可欠で、明確なフォーマッティングは検証を容易にします。 CASE 式は各 WHEN/THEN ペアを表示するようにフォーマットすべき複数行の構造です： SELECT order_id , CASE WHEN status = 'shipped' THEN 'In Transit' WHEN status = 'delivered' THEN 'Complete' WHEN status = 'returned' THEN 'Returned' ELSE 'Processing' END AS status_label FROM orders ネストされた CASE 式（CASE の中の CASE）は、フォーマッティングに関わらず読めなくなるため、可能なときは避けるべきです。代わりに CTE、計算列、またはクエリに結合するルックアップテーブルにリファクタリングしましょう。 INSERT 文には2つの一般的なフォーマットがあります。名前付き列を持つ単一行挿入では、各列と値のペアを読みやすくリストします： INSERT INTO customers ( customer_name , email , country , created_at ) VALUES ( 'John Doe' , 'john@example.com' , 'US' , CURRENT_TIMESTAMP ) VALUES のエントリを対応する列名と整列させると、各値が正しい列に一致することを確認しやすくなります。INSERT...SELECT 文では、標準の SELECT フォーマッティング規則を使って SELECT 部分をフォーマットします。 UPDATE 文は各 SET 代入を独自の行にフォーマットする恩恵を受けます： UPDATE customers SET email = 'newemail@example.com' , updated_at = CURRENT_TIMESTAMP , status = 'verified' WHERE customer_id = 12345 この構造によりどの列が変更されているかが明確になり、テーブルのすべての行を更新する WHERE 句の誤った省略を防げます。UPDATE と DELETE 文の WHERE 句は最も正しく取得することがクリティカルな句です。UPDATE または DELETE と同じレベルで独自の行に WHERE を置くフォーマッティングは、その存在（または不在）を明らかにします。 DELETE 文は常に WHERE 句が明確に見えるようにすべきです： DELETE FROM order_items WHERE order_id = 12345 AND item_status = 'cancelled' WHERE なしの DELETE はテーブルからすべての行を削除します。フォーマットされたコードは WHERE の有無を即座に明らかにします。一部のチームは、どの行が影響を受けるかを確認するために、最初にすべての DELETE クエリを SELECT クエリとして書く（DELETE FROM を SELECT * FROM に置き換える）慣習を採用し、その後 DELETE に戻します。 ウィンドウ関数はフォーマットが最も複雑な SQL 構造の一つです。PARTITION BY と ORDER BY を持つ OVER 句は、長い場合、独自のインデントされた行に置くべきです： SELECT customer_id , order_date , amount , SUM(amount) OVER ( PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders 短いウィンドウ指定では、1行に保つことは許容されます：ROW_NUMBER() OVER (ORDER BY id) AS row_num。目標は実際の式の長さと複雑さでの読みやすさです。名前付きウィンドウ定義（WINDOW w AS (PARTITION BY customer_id ORDER BY order_date)）に続く OVER w は、複数の列が同じウィンドウ指定を使うときの繰り返しを減らします。 キーワードの大文字小文字は両面に強い意見のあるスタイルの選択です。大文字のキーワード（SELECT、FROM、WHERE）は SQL 構文をテーブルと列の名前から視覚的に区別します。小文字のキーワードは溶け込みますが入力が容易です。最も重要なのは一貫性です。1つの慣習を選び、チーム全体で強制しましょう。多くの組織がキーワードに大文字、識別子に小文字を使います。一部のモダンなスタイルガイドはすべてに小文字を好み、エディタのシンタックスハイライトが既にキーワードを識別子から区別していると主張します。第3のアプローチは主要な句のキーワード（SELECT、FROM、WHERE）だけを大文字にし、関数名とマイナーなキーワードは小文字のままにします。 テーブルのエイリアスは意味があるべきです。単一文字のエイリアス（a、b、c）は入力を節約しますが、特に多くの結合ではクエリが読みにくくなります。テーブル名から派生した短い略語がより良いです：customers AS c、orders AS o、order_items AS oi。多くのテーブルを持つ複雑なクエリでは、より長いエイリアスが明確さを向上させます：customers AS cust、order_items AS items。タイポや忘れられたカンマと区別するため、エイリアスには常に AS キーワードを使いましょう。予約語をエイリアスとして絶対に使わないでください。 インデント幅は一貫しているべきです。2スペースと4スペースはどちらも一般的な選択です。タブ対スペースは好みですが、スペースはエディタやツールをまたいでより一貫した整列を生みます。SQL フォーマッターツールはチームの標準に合わせてインデント幅を設定できます。どの幅を選んでも、句の本体、サブクエリのネスト、CASE 式の本体、CTE 定義のすべてのインデントレベルに一様に使いましょう。 SQL のコメントフォーマッティングは単一行コメントに -- を、複数行コメントに /* */ を使います。コメントは、見逃される可能性のある長い行の末尾のインラインではなく、それらが記述する句や式の上に置きましょう。WHERE 句の複雑なビジネスロジックには、フィルター条件の前に条件が存在する理由を説明するコメントが価値があります：-- QA チームが作成したテストアカウントを除外。SQL を復唱するコメント（-- customers テーブルを結合）は価値なしにノイズを加えます。良いコメントは意図を説明し、仕組みではありません。 フォーマッティングとクエリのパフォーマンスは直接関連しません。データベースエンジンは空白と改行に関わらずクエリを解析し最適化します。ただし、よくフォーマットされたクエリは構造が明確に見えるため最適化が容易です。パフォーマンスの問題を持つ不十分にフォーマットされたクエリは、テキストの壁に問題を隠します。同じクエリが適切にフォーマットされると、問題のあるサブクエリ、欠落した結合条件、不必要な DISTINCT、または非サーチ可能な WHERE 句が一目で明らかになります。フォーマッティングはデバッグと最適化のツールです。 バージョン管理と SQL フォーマッティングは重要な形で相互作用します。単一のコミットでクエリ全体を再フォーマットするとすべての行に触れる diff を生み、実際に何が変更されたかを見るのを不可能にします。既存のコードベースにフォーマッターを採用するとき、明確なメッセージ（「SQL フォーマッティング標準を適用」など）とともに専用のコミットでフォーマッティングを行いましょう。その後の変更はきれいで意味のある diff を生みます。先頭カンマが人気の理由の一部は、SELECT に新しい列を追加すると1行の diff（新しい行）を生むのに対し、末尾カンマはカンマを追加するために前の行を変更する必要があり、2行の diff を作るからです。 方言の違いはフォーマッティングの選択に影響します。PostgreSQL、MySQL、SQL Server、Oracle、SQLite、BigQuery はそれぞれ構文のバリエーションを持ちます。PostgreSQL は二重コロンキャスト（value::type）とドル引用文字列を使います。MySQL は識別子にバッククォートを使い LIMIT と OFFSET を使います。SQL Server は角括弧の引用、LIMIT の代わりに TOP、LATERAL JOIN の代わりに CROSS APPLY を使います。Oracle は ROWNUM、階層クエリに CONNECT BY、異なる日付関数を使います。BigQuery はプロジェクト修飾テーブル名にバッククォートを使います。フォーマッターはチームが使う方言を処理すべきです。SQL フォーマッターツールはすべての主要な方言と互換性のある標準 SQL 構文をサポートします。 SQL フォーマッティング標準のチーム導入には、共有設定と、理想的には自動化された強制が必要です。コードスタイルガイドに SQL フォーマッティング規則を含めましょう。SQL ファイルのフォーマットを検証するために pre-commit フックまたは CI チェックを使いましょう。リポジトリにコミットされるツール設定ファイル（.sql-formatter.json のような）で標準を定義しましょう。標準の合意にかかる初期コストは、もはやフォーマットの細かい指摘を含まないすべてのコードレビューと、再フォーマットの演習ではなく読めるコードから始まるすべてのデバッグセッションを通じて回収されます。 アプリケーションコード内の SQL（Python、JavaScript、Java、その他の言語に埋め込まれた）は追加のフォーマット課題を提示します。Python 関数や JavaScript テンプレートリテラル内の生 SQL 文字列は、ホスト言語のフォーマット規則と SQL フォーマット規則の両方に従います。複数行文字列リテラル（Python の三重引用符、JavaScript のバックティック）を使えば、アプリケーションコード内で SQL フォーマッティングを維持できます。SQL 文字列をアプリケーションロジックから分離しましょう：クエリを名前付き定数（const FIND_ACTIVE_USERS = ...）に割り当て、必要な場所で参照します。大規模なクエリコレクションには、SQL を別々の .sql ファイルに移し、実行時に読み込みましょう。 ORM が生成した SQL は多くの場合デバッグのためにフォーマットが必要です。Django、SQLAlchemy、ActiveRecord、または Prisma クエリが予期しない結果を生成するとき、生成された SQL を表示することが問題の診断に役立ちます。ほとんどの ORM は生 SQL を出力する方法を提供します（Knex の query.toString()、SQLAlchemy の str(query)、Django の .explain()）。生成された SQL をフォーマッターに貼り付けて構造を理解しましょう。ORM が生成した SQL は典型的には密集して読みにくいです、人間向けに作られたものではないからです。フォーマットされた出力は結合、条件、サブクエリを見えるようにします。 ストアドプロシージャと関数は、個々のクエリを超えたフォーマットの規律を必要とします。各プロシージャは複数の SQL 文、変数宣言、制御フロー（IF/ELSE、WHILE、FOR）、例外処理（TRY/CATCH、BEGIN/EXCEPTION）を含みます。プロシージャ内の各 SQL 文を標準のクエリフォーマッティング規則を使ってフォーマットしましょう。制御フローの本体をそのキーワードから1レベルインデントします。BEGIN と END を独自の行に置きましょう。プロシージャ内の論理的なセクションの間に空行を追加しましょう。よくフォーマットされたストアドプロシージャは、密集したフォーマットされていないものより劇的にデバッグが容易です。 マイグレーションファイルは、プルリクエストでレビューされ永続的なデータベーススキーマの変更を表すため、SQL フォーマッティングの恩恵を受けます。フォーマットされた列定義を持つ CREATE TABLE 文は、正しいデータ型、制約、null 許容、既定値のレビューが容易です。複数の ADD COLUMN 文を持つ ALTER TABLE は各列を独自の行にリストすべきです。フォーマッティングはマイグレーションのレビューを高速化し、不正な列型や欠落した制約を持つマイグレーションの出荷の可能性を減らします。 パフォーマンス分析クエリ（EXPLAIN、EXPLAIN ANALYZE）は、クエリ自体がフォーマットされているときクエリと関連付けるのが容易な出力を生成します。1行クエリを EXPLAIN ANALYZE に貼り付けると、出力は1行文字列で特定しにくいクエリコンポーネント上の操作を参照します。同じクエリが適切にフォーマットされると、実行計画の各行をクエリの対応する句に一致させられます。この関連付けは、どの結合またはサブクエリがパフォーマンスの問題を引き起こしているかを特定するために不可欠です。 アプリケーションコードでの動的 SQL 生成はフォーマットされた出力を生成すべきです。プログラム的にクエリを構築するとき（ユーザー入力や設定に基づいて SQL 文字列を構築する）、生成されたクエリに改行とインデントを追加しましょう。これは実行時にコストなしですが、ロギングとデバッグを劇的に容易にします。生成されたクエリがエラーを引き起こすかパフォーマンスが悪いとき、ログ内のフォーマットされた SQL を読み、構造を即座に理解できます。すべてを1行に連結することはいくつかの文字を節約しますが、デバッグの頭痛を作ります。 SQL コードレビューのチェックリストはフォーマット標準の恩恵を受けます。フォーマットされた SQL をチェックするレビューアーは系統的に検証できます：各テーブル関係に対する正しい結合タイプ、ビジネス要件に一致する WHERE 句の条件、すべての非集約列を含む GROUP BY、期待される並べ替えを反映する ORDER BY、LEFT JOIN 対 INNER JOIN の適切な使用（INNER で十分なところでの LEFT JOIN はバグまたは不必要な注意のいずれかを示します）、そして本番コードでの SELECT *、暗黙のクロス結合、結合として書き直せる相関サブクエリのような一般的なアンチパターンの不在です。 大規模なレガシークエリのフォーマットは SQL フォーマッターの最も価値ある用途の一つです。エンタープライズデータベースには何年または何十年にもわたって蓄積されたクエリがあります。ずっと前に会社を去った開発者によって書かれ、複数回変更され、フォーマットされたことのないクエリは、誰も触れる勇気のないテキストの壁になります。これらのクエリをフォーマッターに通すことは、それらを保守可能にするための最初のステップです。クエリをフォーマットし、フォーマットの変更を別々にコミットし、その後読める出発点で実際の変更作業を始めましょう。 SQL フォーマッターツールは任意の有効な SQL クエリを取り、その構造を解析し、インデント、キーワードの大文字小文字、句の配置のための設定可能な規則に従って一貫してフォーマットされた SQL を出力します。クエリを貼り付け、フォーマットをクリックし、結果をコピーします。コミット前のクエリのフォーマット、レビューのためのレガシー SQL の整理、同僚から受け取ったまたは ORM ツールが生成したクエリの標準化、ドキュメントやプレゼンテーションのための SQL の準備に使いましょう。
よくある質問
対応している SQL 方言は？
SELECT、JOIN、WHERE、GROUP BY などの一般的な句を含む標準的な SQL 構文に対応しています。
クエリのロジックは変更されますか？
いいえ。空白と大文字小文字のみを変更し、ロジックはそのまま維持されます。
