SQL経験者向けORM入門、CRUDとSQLログで見る確認ポイント

運営中のWebサービスや業務システムでは、ORMを使っていても、実際にどのSQLが発行されているかまでは確認していないことがあります。

画面は動いている。CRUDも書けている。レビューでも大きな指摘は出ていない。

ただ、一覧画面の表示が遅い、テストデータが増えたら急にレスポンスが落ちた、ログを見ると似たようなSQLが何度も出ている。そうなってから、ORMの使い方を見直す場面があります。

以前、当社のベテランから聞いた「SQL経験者がORMを効率よく覚えるルート」が印象的だったので、少し整理します。

ORMはSQLを隠す仕組みとしてだけ捉えない

SQLの経験がある人がORMを覚えるとき、最初から「SQLを書かなくてよい仕組み」として受け取ると、理解しにくいところがあります。

ORMは便利です。モデルやエンティティからデータを取得・登録・更新・削除できるため、単純なCRUDであれば、SQLを毎回手で書かなくても進められます。

ただ、内部でSQLが発行されていることは変わりません。

そのため、最初の入り方としては、ORMをSQLジェネレータとして使う見方が分かりやすいです。普通にCRUDを書いて、SQLログを出し、「このコードを書くと、どんなSQLが発行されるのか」を確認します。

SELECTはどう出ているのか。UPDATEの条件はどうなっているのか。関連テーブルを参照したとき、JOINになるのか、別のSELECTが出るのか。

この確認をすると、ORMの書き方とSQLの結果がつながります。SQL経験者にとっては、抽象化されたAPIを丸暗記するより、出力されたSQLを見た方が理解しやすい場面があります。

私自身も、C言語でコンパイラの出力を眺めていたことがあるので、この感覚は分かります。書いたコードが、最終的にどう変換されているのかを見ると、仕組みの輪郭をつかみやすくなります。

SQLログを見るとORMの動きが確認しやすくなる

ORMの学習で難しいのは、コード上の見た目と実際の処理が一致しているとは限らない点です。

コードだけを見ると、プロパティを参照しているだけに見える。メソッドを一つ呼んでいるだけに見える。けれど、SQLログを見ると、そこでSELECTが発行されていることがあります。

一覧画面で親データを取得し、その後に子テーブルの情報を1件ずつ参照する。画面上はただ一覧を作っているだけですが、ログには似たようなSQLが大量に並びます。

この差分を見ないまま使うと、処理時間が増えたときに原因を切り分けにくくなります。DBが遅いのか、SQLの条件が悪いのか、ORMの関連参照が想定より多く発行されているのか。ログを見ていないと、確認する順番も決めにくくなります。

SQLログは、ORMを疑うためのものではありません。自分が書いたコードが、DBに対してどのような問い合わせになっているのかを確認するための材料です。

N+1問題はローカルで一度確認しておく

そのベテランが話していた中で印象的だったのは、N+1問題を一度わざと踏む、という考え方でした。

一覧と子テーブル参照を書く。SQLログを見る。クエリが大量に出ていることを目で確認する。

言葉だけで「N+1問題はよくない」と覚えるより、ログに同じようなSQLが並ぶ状態を見た方が、腹落ちしやすくなります。

「一度痛い目を見る」という表現もありました。正直、この痛みという言い方は少し分かりにくいところもあります。

ただ、意味としては、本番障害で苦しむという話ではありません。ローカル環境で、練習として遅くなる状態を作り、「これは件数が増えたら厳しいな」と分かる状態にしておく、ということだと思います。

本番で問い合わせが増え、ユーザーの操作に影響が出てから気づくのでは遅くなります。ローカルであれば、ログを増やしても、実験的なコードを書いても、戻しながら確認できます。

練習試合の痛みなので耐えられる、という表現は少し独特です。ただ、起きる現象を安全な環境で見ておくという意味では、実務的な学び方です。

JOIN、Eager、Lazyの判断はSQLを見たあとで整理しやすい

N+1問題を実際に見ると、ORMの機能をどう使い分けるかも考えやすくなります。

JOINを使った方がよい場面があります。Eager Loadingで最初から関連データを取得した方がよい場面もあります。Lazy Loadingで必要になったときだけ取りに行く方が自然な場面もあります。

この選択は、名前だけを覚えても実装時に迷いやすいです。

一覧画面で毎回必要な情報なのか。詳細画面でしか使わない情報なのか。件数が増えたときにクエリ数が増えすぎないか。レビュー時に見るポイントをそろえるには、コードの形だけでなく、発行されるSQLと画面の使われ方を一緒に確認した方が判断しやすくなります。

ORMでやってよいことと、注意した方がよいことも、ここから整理できます。

単純なCRUDはORMに任せやすいです。画面表示に必要な関連データをまとめて取る処理は、ログを見ながら書き方を確認した方が安心です。件数が増えるテーブルや、アクセスが多い画面では、SQLの本数、JOINの条件、インデックスの使われ方まで見た方が原因を切り分けやすくなります。

ORM学習で確認しておきたいポイント

ORMを覚えるときは、機能名を順番に覚えるより、書いたコードがどんなSQLになるのかを確認する方が理解しやすい場面があります。

特にSQL経験者であれば、SQLログはかなりよい入口になります。抽象化された書き方をそのまま受け入れるのではなく、生成されたSQLを見て、知っているSQLの感覚とつなげられるからです。

学習やレビューでは、次のような点を見ておくと、次に何を確認するか決めやすくなります。

・CRUDを書いたあと、発行されるSQLをログで確認する
・一覧画面と子テーブル参照を組み合わせ、SQLの本数を見る
・同じようなSELECTが大量に出ていないか確認する
・JOIN、Eager Loading、Lazy Loadingのどれが画面の使われ方に合うかを見る
・件数が増えたとき、レスポンスが遅くならないかテストデータで確認する
・原因がはっきりしない場合は、画面操作、発行SQL、件数、実行時間を分けて記録する

ORMは、SQLを隠すためだけのものではありません。

SQLを書かずに済む場面を増やしながら、必要なときには発行されるSQLを確認できる状態にしておく。そこまで含めて使えるようになると、実装時に迷いにくくなります。

レビューでも、単に「ORMの書き方として正しいか」だけでなく、「この画面でこのSQLの出方なら問題が出にくいか」を確認しやすくなります。

SQL経験者がORMを覚えるなら、最初の入口は機能一覧ではなく、CRUDとSQLログで十分かもしれません。そのうえでN+1問題をローカルで一度確認しておくと、ORMに任せやすい処理と、注意して見るべき処理を分けやすくなります。

おわりに

X（旧Twitter）やBlueskyを中心に日々発信しております。
是非他のSNSもご覧いただけますと幸甚でございます。

https://x.com/itchie_tatsumi
https://bsky.app/profile/itchie-tatsumi.bsky.social
https://www.facebook.com/ichino.souta

また、辰巳電子工業SS事業部では、エンジニアが安心して長く働ける環境づくりに取り組んでおります。「今の経験で応募できるか知りたい」「案件やキャリア支援について聞いてみたい」という方は、是非カジュアル面談からお気軽にご相談願います。

https://www.tatsu-mi-systemsolution.jp/