レビューで毎回指摘されるSQLの書き方問題を一発解決する整形テクニック

導入：「このSQL、読めないんだけど…」

男の子

「博士！コードレビューで先輩に『このSQL読めない』って突き返されたんだぜ！ちゃんと動くのに！」

博士

「動くかどうかと、読みやすいかどうかは別問題じゃ。特にSQLは1行に詰め込みがちで、可読性が犠牲にされやすいのじゃよ。」

女の子

「SQLのフォーマットが統一されてないと、WHERE句の条件を見落としてバグの原因になることもあるわよね。」

1. 読みにくいSQLが引き起こす「現場の事故」

博士

「実際の開発現場で、SQLの読みにくさが原因で起きた事故を紹介しよう。」

事故パターン：WHERE句の見落とし

-- 💀 1行SQLの悲劇：全ユーザーの情報が削除された
DELETE FROM users WHERE status = 'inactive' AND created_at < '2024-01-01' AND department_id IN (SELECT id FROM departments WHERE is_deleted = 1)

男の子

「う…確かに1行だと、どこまでがWHERE条件なのか一瞬わからないぜ。」

SQLの読みにくさが招く事故

WHERE句の条件漏れ：1行SQLではANDやORの条件を見落としやすい
JOIN先テーブルの誤認：複数テーブルの結合条件が混在して誤ったデータを取得
レビュー工数の増大：読み解くのに時間がかかり、レビューが形骸化
コピペミスの誘発：既存SQLを修正する際にインデントがなく修正箇所を見誤る

2. SQL整形ツールで「安全で読みやすいSQL」に変換

博士

「先ほどの危険な1行SQLを、適切にフォーマットするとこうなるのじゃ。」

-- ✅ 整形後：条件が一目瞭然
DELETE FROM
    users
WHERE
    status = 'inactive'
    AND created_at < '2024-01-01'
    AND department_id IN (
        SELECT id
        FROM departments
        WHERE is_deleted = 1
    )

女の子

「こうすると各条件が1行ずつになるから、レビュー時にGitのdiffでも変更箇所が明確になるのよね。」

当サイトのSQL整形ツールを使えば、ぐちゃぐちゃなSQLをワンクリックで読みやすいフォーマットに変換できます。レビュー前のSQLチェックや、ログから取得した実行クエリの解析にも便利です。

3. プロが教える「一歩先の」テクニカルTips

博士

「読みやすいだけでなく、安全で効率的なSQLを書くためのプロの流儀を教えよう。」

Tips 1: SELECT * を使わない

SELECT * はすべてのカラムを取得するため、テーブル構造の変更に弱く、パフォーマンスも悪化します。必要なカラムだけを明示的に指定することで、意図が明確になり、インデックスの恩恵も受けやすくなります。

Tips 2: エイリアスで意図を明示する

複数テーブルをJOINするとき、テーブルにエイリアス（略称）を付けるのはもちろん、全カラムにテーブルプレフィックスを付けるのがプロの流儀です。u.name と d.name を区別でき、カラム名の衝突事故を防げます。

Tips 3: DELETEやUPDATEの前にSELECTで確認

本番でDELETE文やUPDATE文を実行する前に、同じWHERE条件でSELECTを実行して対象件数を確認するのは基本中の基本です。「思ったより多い」と感じたら、条件の見直しが必要なサインです。

🚨 現場の注意点：本番SQLは必ずトランザクションで囲む

本番環境でのDELETEやUPDATEは必ず BEGIN TRANSACTION で囲み、結果を確認してから COMMIT してください。想定と違う結果が出たら ROLLBACK で安全に巻き戻せます。「とりあえず実行」は絶対に避けましょう。

パソコン博士

「SQLは『動けばOK』ではなく、『誰が読んでも意図が伝わる』ことが大切じゃ。まずはSQL整形ツールで自分のSQLを整形してみて、読みやすさの違いを体感するのじゃ！」