SQLは動けばよい、で済ませるとレビューが重くなります。
特にJOINやサブクエリが入ると、整形されていないSQLは条件の見落としにつながります。

SQL Formatterを使うと、クエリの構造を先に整えてからレビューできます。

こんなSQLを読むとき

select users.id, users.name, count(orders.id) as order_count from users left join orders on users.id = orders.user_id where users.status = 'active' group by users.id, users.name order by order_count desc;

整形すると、読みたい単位が分かれます。

SELECT
  users.id,
  users.name,
  COUNT(orders.id) AS order_count
FROM users
LEFT JOIN orders
  ON users.id = orders.user_id
WHERE users.status = 'active'
GROUP BY
  users.id,
  users.name
ORDER BY order_count DESC;

この形なら、JOIN条件、絞り込み条件、集計条件を別々に確認できます。

実例：APIデバッグとSQL確認をつなげる

APIのレスポンスが想定と違うときは、ブラウザのNetworkタブからリクエストをCurlとしてコピーし、再現コードを作ってからSQLログを確認する流れがよくあります。

curl 'https://example.com/api/users?status=active' \
  -H 'Authorization: Bearer token'

リクエスト条件を再現できたら、サーバーログに出たSQLを整形します。

select * from users where status = 'active' and deleted_at is null order by created_at desc;

APIの入力条件とSQLの WHERE が対応しているかを見比べることで、フロントエンドのパラメータ漏れなのか、バックエンドのクエリ条件漏れなのかを切り分けやすくなります。

レビュー前に見るポイント

  • SELECT句に不要な列が入っていない
  • JOIN条件が意図したキーになっている
  • WHERE句で除外しすぎていない
  • GROUP BYの列がSELECT句と対応している
  • ORDER BYが期待する並び順になっている

整形はSQLを正しくする作業ではありません。
ただし、正しくない箇所を見つけやすくする作業としてかなり有効です。

SQL Builderとの使い分け

SQL Builderでクエリの骨組みを作り、SQL Formatterで最終確認する流れにすると、作成とレビューの役割を分けられます。
SQLを書き慣れていない人の学習にも、レビュー前のセルフチェックにも使いやすい流れです。

Curlコマンド変換ツールを併用すると、API再現コード、SQL整形、レビューコメントを同じ流れで作れます。再現条件を先に固定してからSQLを見ると、調査の前提がずれにくくなります。

関連ツール