「このクエリ、密すぎて読めない……」

運用中のシステムから吐き出された、一行に固まった巨大なSQL。あるいは複雑なJOINが何層にも重なったストアドプロシージャ。「どこで条件が分岐しているの？」と画面を睨みつけたことはありませんか？

SQLフォーマッター は、貼り付けたSQLをブラウザ内で整形するツールです。すべてローカルで処理されるため、機密性の高いクエリでも外部に送信されません。

SQLフォーマッターでクエリを読みやすく整形する方法

Before / After

select users.id,users.name,count(orders.id) from users left join orders on users.id=orders.user_id where users.deleted_at is null group by users.id,users.name order by users.id desc;
SELECT
  users.id,
  users.name,
  COUNT(orders.id)
FROM users
LEFT JOIN orders ON users.id = orders.user_id
WHERE users.deleted_at IS NULL
GROUP BY
  users.id,
  users.name
ORDER BY users.id DESC;

見た目が整うだけで、条件の抜け・JOINの向き・集計単位の誤りに気づきやすくなります。

なぜ「方言（dialect）」の指定が必須なのか

SQLフォーマッターは、入力をトークナイズして構文を理解してから改行やインデントを組み立てます。そのため、SQLの実装ごとの拡張仕様（方言）を知らないと、正しく整形できません。

方言差の例Standard SQLMySQLPostgreSQLBigQuery
識別子の引用"name"`name`"name"`project.dataset.table`
文字列連結||CONCAT()||||
LIMIT構文LIMIT nLIMIT nLIMIT n OFFSET mLIMIT n
配列/構造体非標準非対応ARRAY[...]STRUCT<...>

たとえばMySQLのバッククォート識別子を Standard SQL としてパースすると、トークンの境界がズレて整形結果が崩れることがあります。「整形がおかしい」の原因の大半は方言の選択ミスです。ツールでは PostgreSQL / MySQL / MariaDB / SQL Server / BigQuery など主要な方言 を選択でき、方言を切り替えると自動で再整形されます。使用中のデータベースに合わせて選ぶようにしてください。

SQLレビューで見るべきポイント

整形しただけの状態から、さらにレビューの質を上げるための確認項目です。

  • WHERE 条件が意図通りか
  • JOIN の条件が不足していないか
  • LEFT JOIN と INNER JOIN の使い分けが正しいか（SQL JOIN完全リファレンス にJOIN種類ごとの違いをまとめています）
  • GROUP BY の粒度が期待通りか
  • ORDER BY や LIMIT が必要な場面で指定されているか
  • サブクエリやCTEの責務が分かりやすいか

とくにログから拾ったSQLは、プレースホルダーが展開済みで長くなりがちです。整形してから読むだけで調査時間を大きく減らせます。

整形は「見た目」以上の仕事をする

フォーマッターを通す価値は、見た目が整うこと自体よりも副次効果にあります。

  1. 構文エラーの早期発見: パースに失敗する＝どこかが壊れている。実行前の簡易チェックになる
  2. 差分レビューが利く: 整形規則を固定すると、クエリ変更のdiffが「実質的な変更」だけになる
  3. ORMの出力の解読: 機械生成の1行SQLは、整形して初めて何をJOINしているかが見える

とくに1つ目は見落とされがちですが、閉じ括弧の数が合わない・カンマが抜けているといったミスは、整形処理がエラーを返すことで気づけます。

よくある質問

MySQLやPostgreSQLのSQLに対応していますか？

はい。主要なSQL方言（Standard SQL / MySQL / PostgreSQL / MariaDB / SQL Server / BigQueryなど）に合わせて整形できます。方言固有の構文が含まれる場合は、整形後に実行前の確認を行ってください。

整形するとSQLの意味は変わりますか？

通常、整形は空白・改行・インデント・大文字小文字を調整する処理で、クエリの意味（実行結果）は変わりません。ただし実行前には、必ず元のSQLと意図が変わっていないか確認するのが安全です。

方言を間違えて選ぶとどうなりますか？

識別子の引用符やキーワードの解釈がズレるため、インデントが崩れたり、意図しない位置で改行されたりすることがあります。「整形結果がおかしい」と感じたら、まず方言の選択を見直してください。

機密データを含むSQLを貼っても大丈夫ですか？

はい。整形はすべてブラウザ内で完結し、ネットワーク通信は発生しません。テーブル名やカラム名を含むクエリでも、外部に送信されることなく処理されます。

まとめ

  • SQLフォーマッターの本体はライブラリへの1行の委譲だが、方言指定が結果を左右する本質的なパラメータ
  • 識別子の引用符ひとつでパースが変わるため、使用中のDBに合わせて方言を選ぶ
  • 整形は見た目のためだけでなく、構文エラーの早期発見・diffの安定化・機械生成SQLの解読に効く

ログから拾ったクエリの解読に、ぜひ使ってみてください。