圧縮された SQL クエリを貼り付けるだけで読みやすいインデント付き出力に。方言・インデント幅・キーワードの大文字小文字を選べ、すべてブラウザー内で処理します。
壁のような SQL を、もう一度読める形に。 1 行でも 1000 行でも、クエリを貼り付ければ入力と同時に整形されます。方言特有の構文が壊れないよう先に方言を選び、続いてチームで使っているインデントとキーワードの大文字小文字を指定してください。
SQL 整形ライブラリの読み込みに失敗しました。ページを再読み込みしてください。
SQL が標準であるのは、英語の綴りが標準であるのとだいたい同じ程度の意味です。どのエンジンも共通コアを実装したうえで、他にはない構文を独自に追加します。対象エンジンを知らない整形ツールは、そうした構文を誤って解析するか、黙って未整形のまま素通しするかのどちらかです。
その違いは決して珍しいものではありません。識別子の引用符だけでも陣営が分かれます。MySQL はバッククォート、PostgreSQL と標準 SQL は二重引用符、SQL Server は角括弧です。誤った規約を前提にした整形ツールは、引用符付き識別子を文字列リテラルと解釈し、存在しない境界を軸にクエリを折り返してしまいます。引用符以外にも、LIMIT と TOP と FETCH FIRST の違い、PostgreSQL の :: キャスト演算子、@ 始まりの T-SQL 変数、バッククォートで囲む BigQuery のプロジェクトパス、Snowflake の QUALIFY 句などがあります。正しい方言を選ぶことが、これらを保つ唯一の方法です。
インデント幅とキーワードの大文字小文字は見た目の問題に思えますが、実際にはバージョン管理履歴の姿を決めます。整形は一貫している場合にのみ役に立ちます。同じファイルを 2 人が別々の流儀で整形した瞬間、すべてのコミットに無関係な空白差分の波が乗り、コードレビューが機能しなくなるからです。設定を 1 つ決め、リポジトリに書き込み、機械的に適用してください。
キーワードの大文字化は最も一般的な慣習で、密度の高いクエリを読むときに役立ちます。構造を示す語がテーブル名や列名と視覚的に分離されるからです。SQL を普通のコードとして扱い、「叫ぶ」書き方を好まないコードベースでは小文字も広まってきました。「元のまま」は、他人のクエリを整形する際に本文を 1 文字も変えずレイアウトだけ整えたい場合に正解で、差分は純粋に構造的なものになります。
タブかスペースかという恒例の議論には、SQL 固有の事情が 1 つあります。クエリはターミナル、チケットシステム、チャットクライアントに貼り付けられることが多く、これらはタブを 8 桁幅で表示しがちです。タブでインデントした深いネストのクエリは、まさに共有する可能性が最も高い場所で読めない折り返しを起こします。
整形は純粋に表示上の処理です。クエリが速くなることはなく、オプティマイザーが生成する実行計画も一切変わりません。美しくインデントされた相関サブクエリも、依然として行ごとに 1 回実行されます。性能改善には EXPLAIN を、可読性には整形ツールを使ってください。
検証も行いません。本ツールはテキストを再配置できる程度には解析しますが、エンジンのパーサーではないため、列名を打ち間違えたクエリや結合条件が抜けたクエリも平然と整形します。整形がきれいであることは構文チェックではなく、クエリが有効かどうかを判定できるのは、それを実行するつもりのデータベースだけです。
整形とあわせて身につける価値がある習慣はパラメーター化です。値を文字列に連結したクエリを整形しても、インジェクションのリスクが読みやすくなるだけで、危険度は変わりません。ユーザー入力が直接埋め込まれた SQL を整形している自分に気づいたら、真っ先に直すべきは整形ではありません。