JavaのSQL実行が遅い原因はどこ？計測ポイントと改善策を一気に整理

この記事でわかること（結論と最短の方針）

Javaで「SQLが遅い」と感じたときは、まず原因の場所を切り分けると最短で改善できます。

切り分けができると、SQLチューニングに走る前に「今やるべきこと」が明確になります。

体感の遅さはSQLそのものではなく、接続待ちや変換処理などJava側の時間が支配していることがよくあります。

とくにピーク時は、DBが速くてもアプリ側の待ちが積み上がって一気に遅く見えることがあります。

最初に「どこを見るか」を固定し、計測してから打ち手を当てるだけで、無駄なチューニングを避けられます。

この記事では、現場でありがちな原因と、効果の出やすい順での改善手順をまとめます。

まず疑う場所は3つ（DB・SQL・Java実行経路）

遅さの発生点は大きく「DB」「SQL」「Java実行経路」に分けて考えると整理しやすいです。

この3つは、調査の観点と担当領域が分かれるため、最初に言語化するとチーム内で共有しやすくなります。

DBはCPUやI/O、ロック、接続上限などで詰まります。

DB側が詰まっている場合は、アプリをいくら最適化しても改善幅に天井が出ます。

SQLは実行計画やインデックス、取得件数の多さで詰まります。

同じSQLでもパラメータ分布や統計情報で計画が変わるため、「速い時と遅い時」が混在することもあります。

Java実行経路は接続待ち、ORMの余計な発行、変換、ネットワーク往復などで詰まります。

Java実行経路の問題は、ログとメトリクスを揃えるだけで急に見えるようになることが多いです。

先に見るべき計測ログ4点（SQL/実行時間/件数/接続待ち）

最初の計測は「SQL」「実行時間」「件数」「接続待ち時間」の4点だけでも効果があります。

この4点は、原因を大別するための最小セットであり、入れるコストの割にリターンが大きいです。

この4点が揃うと、SQLが重いのか、待ちが重いのか、件数が多すぎるのかを短時間で判断できます。

さらに、同じSQLでも「件数が多い時だけ遅い」のような条件付きの問題も見つけやすくなります。

ログが揃っていない状態で対策を始めると、改善したつもりで別の場所を悪化させることがあります。

対策前後で比較できないと、効果測定ができず、改善が属人的になる点にも注意が必要です。

最短で効きやすい改善トップ5

効果が出やすい順に並べると、接続待ちの解消、逐次実行の一括化、fetchSizeとbatchSizeの調整、ORMの発行SQL制御、取得件数の削減が上位に来ます。

上位ほど「往復回数」や「待ち」を減らす施策なので、改善の幅が大きく、影響範囲も読みやすいです。

どれも「往復回数」「待ち時間」「不要処理」を減らす方向なので、DB種類に依存しにくいです。

一方で、値を大きくしすぎるとメモリやロックに跳ね返るため、段階的に調整する前提で扱います。

この後の章では、原因ごとに症状と対策を対応付けて説明します。

最終的には「どこが支配的か」を確定し、最少手数で改善することがゴールです。

JavaでSQL実行が遅くなる原因はSQLだけではない（全体像）

アプリの「SQL実行が遅い」は、DBに送って返ってくるまでの全工程が合算された時間として観測されます。

そのため、同じSQLを別ツールで実行すると速いのに、アプリからだと遅いという現象が起きます。

そのため、SQLそのものを速くしても、体感が変わらないケースが現場では頻出します。

逆に言えば、SQLを触らなくてもアプリの経路を直すだけで体感が劇的に改善することもあります。

ここでは、実行時間の内訳を把握してから原因に当てる考え方を整理します。

内訳が分かると、担当者間の押し付け合いではなく、データに基づいて対策を決められます。

「実行時間」に含まれるもの（待ち・変換・ネットワーク）

実行時間には、コネクションを借りる待ち時間が含まれます。

この待ち時間は、ピーク時にだけ跳ねやすく、テスト環境では再現しにくいです。

実行結果をResultSetからオブジェクトに変換するCPU時間も含まれます。

変換は「行数×列数×変換ロジック」の掛け算で増えるため、件数が多いと急に支配的になります。

ページングせず大量件数を取り、ネットワーク転送とデシリアライズで時間を使うこともあります。

ネットワーク転送は遅延だけでなく、帯域とバッファの影響でスパイクが起きることがあります。

さらに、同じ処理を複数回呼ぶ設計だと、往復回数の積み上げが支配的になります。

往復回数の問題は、個々のSQLが速いほど見落としやすいので注意が必要です。

「EXPLAINは速いのに遅い」典型症状と指標

EXPLAINで問題が見えないのに遅いときは、接続待ちや往復回数が疑わしいです。

まずは「DBでの実行時間」と「アプリでの観測時間」の差を取り、その差分が大きいかを確認します。

接続待ちは「取得待ち時間」やプールの待機数が増えていることで気づけます。

待機数が増えると、タイムアウトが連鎖し、さらにリトライで負荷が増える悪循環に入ります。

変換CPUは、DB時間が短いのにアプリのCPU使用率が高いときに疑えます。

プロファイラでホットスポットが変換やシリアライズに集中していれば、SQLより先に直すべきです。

往復回数は、短いSQLが大量に発行されているログで見分けやすいです。

同じテンプレートのSQLが短時間に何十回も出ているなら、まとめる余地が高いです。

大量取得は、件数が多いのに必要な列や行を絞れていないときに起きます。

このケースは、fetchSizeやページングと組み合わせると改善が一気に進みます。

Java側で遅くなる主な原因（原因別：症状→原因→対策→注意）

Java側のボトルネックは、見え方のパターンがある程度決まっています。

見え方が分かると、調査の当たりを付けやすく、最初の一歩を外しにくくなります。

この章では、各原因を「症状」「原因」「まず試す対策」「注意点」で揃えて整理します。

同じ型で並べることで、原因が違っても比較しやすく、優先順位も付けやすくなります。

先に大きな改善が出やすいところから手を付けると、全体の時間を一気に削れます。

改善が出た後に細部を詰めると、手戻りが減り、最終的な品質も上げやすいです。

EJBや重いデータアクセス層を経由している

症状として、1回のDBアクセスが短いはずなのに、呼び出し全体が妙に遅く見えます。

とくに呼び出し階層が深いほど、ログの粒度が粗いと原因が埋もれます。

原因は、リモート境界のシリアライズや、層のまたぎで付随処理が増えることです。

認可・トレース・変換などの横断処理が重なると、SQL以外の時間が膨らみやすいです。

対策は、境界を跨ぐ回数を減らし、DBアクセスはまとめて行う形に寄せることです。

加えて、同じデータを取りに行く重複呼び出しを統合できると、改善幅が大きくなります。

注意点として、設計の都合で責務分離を崩すと保守性が落ちるため、計測で効果が出る箇所から限定して見直します。

まずは「遅い経路だけ」を対象にし、他の経路は触らない方が安全です。

EJBからJDBC寄りへ見直す判断チェック

症状として、処理時間がネットワークやフレームワークのオーバーヘッドに見える場合があります。

同時に、例外処理やリトライが絡むと、遅さがさらに増幅して見えることもあります。

判断のチェックは、リモート呼び出しが多いか、DTOが巨大か、境界を跨いでトランザクションが長いか、ログに同じSQLが細切れで出ていないかです。

これらが複数当てはまるほど、JDBC寄りへの局所最適が効きやすい傾向があります。

対策は、パフォーマンスが要求される経路だけをJDBC寄りに寄せ、他は従来の抽象化を保つ折衷案を採ることです。

具体的には、読み取りはJDBCで最適化し、更新はORMの利点を生かす分離も有効です。

注意点として、全面置換はリスクが高いので、局所最適から始める方が安全です。

移行対象が広がるほどテストコストが増えるため、範囲を小さく保ちます。

段階移行の進め方（計測→部分置換→戻し手順）

最初に現状の計測点を固定し、前後比較できる状態にします。

計測点は、ユーザー体感に近い入口と、DBアクセス直前直後の両方に置くと効果的です。

次に最も遅い経路だけを部分的に置換し、効果が見えたら範囲を広げます。

このとき、置換前後でSQL発行回数や件数がどう変わったかも同時に確認します。

最後に戻し手順を用意し、想定外の副作用が出たときにすぐロールバックできるようにします。

戻し手順があると、挑戦的な最適化も安心して試しやすくなります。

ORM/JPAが不要なSQLを発行している（N+1/不要SQL/フェッチ/更新）

症状として、短いSQLが大量に発行され、合計時間が膨らみます。

SQLが大量に出るほど、DBだけでなくネットワークとアプリCPUの負担も増えます。

原因はN+1、不要なJOINやカラム取得、フェッチ戦略のミスマッチ、更新を1件ずつ発行する設計です。

とくに関連を辿る設計は便利ですが、無意識に往復回数を増やしやすいです。

対策は、発行SQLをログで可視化し、必要な単位でまとめて取得し、更新はバッチ化することです。

合わせて、取得する列を減らし、返却オブジェクトを軽くするだけでも体感が変わることがあります。

注意点として、フェッチを無闇にEAGERにするとメモリと転送量が増えるため、件数と列数の見積もりが必要です。

性能とメモリのトレードオフを意識し、対象データの上限を決めてから調整します。

ResultSetからの変換処理が重い

症状として、DB時間は短いのに、アプリの処理が戻ってくるまで長く感じます。

大量取得のときほど顕著で、CPUとGCが増えてレスポンスが不安定になります。

原因は、反射ベースのマッピング、多段のDTO変換、巨大オブジェクトの生成、JSON化などの追加処理です。

同じデータを何度もコピーしたり、不要なフィールドを埋めたりすると無駄が積み上がります。

対策は、必要列だけを取得し、DTOを最小化し、変換ロジックを軽量化することです。

可能なら、変換を遅延させたり、ストリーミングで扱ったりしてピーク負荷を下げます。

注意点として、軽量化のために型安全性や可読性を落としすぎると運用でコストが増えます。

まずは「不要な変換を減らす」ことから始め、最後に最適化の深掘りをします。

接続プール設定が適切でない（枯渇→待ち→タイムアウト）

症状として、ピーク時だけ遅くなり、時々タイムアウトが起きます。

平常時は問題が出ないため、リリース後に初めて気づくパターンもあります。

原因は、プールが枯渇して接続取得待ちが発生し、待ち行列が積み上がることです。

待ちが長くなると、上流のスレッドが塞がり、全体のスループットが落ちます。

対策は、同時実行数とDBの上限を踏まえてプールサイズを調整し、待ち時間のメトリクスを監視することです。

同時に、接続リークがないか、長時間トランザクションがないかも点検すると効果的です。

注意点として、プールを増やしすぎるとDB側でスレッドやメモリが枯渇するため、DBの許容量も必ず確認します。

設定値は「アプリ都合」だけで決めず、DBの最大接続と運用方針に合わせます。

PreparedStatementを使わず毎回SQLを組み立てている

症状として、同じ内容の検索なのに毎回微妙に文字列が違い、DB側の負荷が揺れます。

文字列連結が多いと、ログも読みづらくなり、調査効率が落ちます。

原因は、SQL文字列生成のコストと、DB側のパースやプランキャッシュの効きにくさです。

SQLの形が安定しないと、計画が毎回変わり、性能がブレる要因になります。

対策は、PreparedStatementでパラメータ化し、SQLの形を安定させることです。

合わせて、バインド変数の型が適切かを揃えると、計画の安定にもつながります。

注意点として、性能だけでなくSQLインジェクション対策としても必須です。

パラメータの扱いを統一すると、コード品質と保守性も改善します。

1件ずつSQLを実行している

症状として、単発は速いのに、件数が増えると比例して遅くなります。

件数が増えるほど、遅さがほぼ直線的に伸びるのが特徴です。

原因は、ネットワーク往復とトランザクションのオーバーヘッドが件数分だけ増えることです。

さらに、ロックやログ書き込みが増えると、DB側の待ちも増えることがあります。

対策は、IN句や一括更新、バッチ実行でまとめて処理することです。

更新の場合は、同じテーブルへの連続更新をまとめるだけでも効果があります。

注意点として、まとめすぎるとロックやメモリが増えるため、適切な分割サイズが必要です。

「一括＝無制限」ではなく、運用で安全な上限を決めて分割します。

fetchSize/batchSizeの未調整で往復回数が増える

症状として、取得や更新が小刻みになり、全体がじわじわ遅くなります。

ログに出るSQLが少なくても、内部でのフェッチが細かく、往復が増えていることがあります。

原因は、ドライバやORMの既定値が小さく、結果取得や更新が分割されて往復が増えることです。

既定値は汎用的に安全側なので、高スループット用途では不足になりがちです。

対策は、取得はfetchSize、更新はbatchSizeを調整して往復回数を減らすことです。

合わせて、結果をページングで扱うと、メモリとレイテンシの両方が安定します。

注意点として、値を大きくしすぎるとメモリ使用量が増えるため、件数と行サイズを見ながら決めます。

テストは、最大件数に近いデータで行い、ピークで破綻しないことを確認します。

トランザクション範囲が広すぎる

症状として、他の処理も巻き込んで遅くなり、時間帯によってバラつきます。

同時に、ロック競合で待ちが増えると、遅い処理がさらに遅い処理を生む状況になります。

原因は、ロック保持時間が長くなり、競合と待ちが連鎖することです。

外部I/Oや重い計算をトランザクション内で行うと、保持時間が伸びやすいです。

対策は、トランザクションを必要最小限にし、I/Oや外部呼び出しをトランザクション外に出すことです。

加えて、更新の順序を揃えてデッドロックの可能性を下げることも有効です。

注意点として、整合性要件を満たす範囲で縮める必要があるため、業務要件の確認が欠かせません。

正しさを犠牲にして速くするのではなく、要件に合う範囲で設計を調整します。

Java側の遅さをどう計測・切り分けるか

改善で最も重要なのは、最初に「どこが遅いか」を確定させることです。

確定できれば、次に打つ手は少なくなり、改善の再現性も上がります。

計測が弱いと、対策の優先順位がぶれて改善が長引きます。

さらに、環境差やデータ差で議論が空中戦になり、関係者の合意が取りづらくなります。

ここでは最小の計測セットから、道具の使い分けまでをまとめます。

迷ったら、まずはログの整備から始めるのが最短です。

まずログに出すべき4点（SQL/実行時間/件数/接続待ち）

SQLはプレースホルダ付きの形で記録し、形が安定しているかを見ます。

同じ意図のSQLが複数の形で出ているなら、生成箇所の統一が改善につながります。

実行時間は、DB実行だけでなく接続取得や結果変換を含むかを明確にします。

計測範囲が混ざると、改善しても数字が動かないように見えるため、定義を先に決めます。

件数は、返ってきた行数だけでなく取得したページサイズも残します。

件数と時間の相関が取れると、「件数が増えると遅い」問題の検出が簡単になります。

接続待ちは、プールから借りるまでの待ち時間を別に測ると切り分けが一気に進みます。

待ち時間の分離ができると、SQLやインデックスの議論に入る前に原因が確定することもあります。

APM・プロファイラ・DB側統計の使い分け

APMは、遅いトランザクションとその内訳を広く把握するのに向いています。

本番相当の負荷で傾向を見るのに強く、外形監視とも相性が良いです。

プロファイラは、変換処理やシリアライズなどアプリCPUのホットスポットを突き止めるのに向いています。

CPUだけでなく、アロケーションが多い箇所を見つけるとGC起因の遅さも追えます。

DB側統計は、実行回数が多いSQLや待機イベントを見つけるのに向いています。

アプリが速くてもDBが詰まっている場合は、ここで根本原因が見えることがあります。

同じ結論に複数の観点で到達できると、対策の確度が上がります。

複数の証拠が揃うほど、対策の優先順位と投資判断がしやすくなります。

再現条件を固定する（キャッシュ/並列度/データ量）

キャッシュの有無で結果が変わるため、ウォームアップと計測本番を分けます。

キャッシュが効いている状態だけを見ても、ピーク時の遅さの説明にならないことがあります。

並列度が変わると接続待ちが変化するため、同時実行数を固定します。

スレッド数やキューの設定も一緒に揃えると、より再現性が上がります。

データ量が違うと実行計画が変わるため、対象データの範囲を揃えます。

テーブルの統計やインデックスの状態が変わると結果も変わるため、環境情報も記録します。

計測の前後で条件が揺れると、改善が効いたのか分からなくなります。

「同じ条件で比較できる」状態が、改善の最後まで一番重要です。

SQL側で見直すべき代表的なポイント

Java側を最適化しても、SQLやDBがボトルネックなら限界があります。

ただし、SQL側は「基本だけで大きく改善する」領域も多いです。

基本の確認は手数が少ない割に効果が大きく、最初に押さえる価値があります。

ここではDB種類を限定しない共通観点に絞って整理します。

個別DBの最適化はこの後の深掘りとして、まずは共通で効くところから始めます。

インデックスと実行計画の基本

遅いSQLは、まず実行計画を見て意図したインデックスが使われているか確認します。

計画が意図と違う場合は、条件式の書き方やデータ分布が原因になっていることがあります。

条件の選択性が低いと全表走査になりやすいので、絞り込み条件の設計も見直します。

必要なら、検索頻度の高い条件に合わせてインデックスを追加または組み替えます。

複合インデックスは列順で効き方が変わるため、最頻の検索パターンに合わせます。

同じクエリでも「先頭列が一致しない」と効かない場合があるので、設計時に注意します。

計画が変わりやすい場合は、統計情報やパラメータの分布も疑います。

計画のブレが大きいときは、パラメータの典型値で複数ケースを確認します。

取得件数を減らす（必要列・ページング・条件）

取得する列を必要最小限にすると、転送と変換の両方が軽くなります。

列が多いほど1行あたりのサイズが増え、転送とメモリの負担が増えます。

ページングで一度に返す行数を制御すると、メモリとレイテンシが安定します。

ユーザー体感は「最初のページが速い」だけでも改善することが多いです。

条件の書き方でインデックスが使えないことがあるため、関数適用や型変換がないか確認します。

曖昧検索や前方一致の要件がある場合は、別の検索戦略を検討する余地もあります。

JOIN/集計/サブクエリの重さの見方

JOINは行数が増えやすいので、結合前後の件数を意識して設計します。

不要なJOINは削るだけでなく、必要なJOINでも列を絞ると負荷が下がります。

集計はソートやハッシュでメモリを使うため、必要な範囲に絞った上で実行します。

集計対象が大きい場合は、事前集計やキャッシュの戦略も検討します。

サブクエリは形によっては繰り返し実行されるため、結合やCTEへの変形を検討します。

実行計画で「繰り返し」「相関」が見えるときは、構造の見直しが効きやすいです。

実務で効果が出やすい改善順序（ロードマップ）

改善の順序を間違えると、手数は増えるのに効果が出ない状態になります。

とくに、計測なしでSQLだけを触ると、当たり外れが大きくなりがちです。

さらに、場当たり的な変更は副作用の切り分けが難しく、元に戻す判断も遅れます。

まず計測し、次に改善幅の大きい領域を先に潰すのが現実的です。

改善幅の大きい領域を先に片付けると、以降の細かな改善も効いているかが分かりやすくなります。

同時に、関係者へ説明できる根拠が揃うため、合意形成も速く進みます。

ここでは現場で再現性が高い順にロードマップ化します。

ロードマップを一度作ると、次回以降の障害対応も同じ手順で進められます。

加えて、運用中に遅さが再発したときも、同じ観点で比較できるようになります。

Step1：計測→切り分け

最初にログとメトリクスで、接続待ち、往復回数、変換CPU、DB実行のどれが支配的かを確定します。

このとき、入口の外形時間と、DBアクセス直前直後の時間を別に測ると差分が見えます。

支配的な要因が決まると、次の一手がほぼ自動的に決まります。

迷ったときは「差分が一番大きいところ」から潰すと、改善の確率が上がります。

計測の結果はスクリーンショットやメモで残し、改善前後で比較できる形にします。

Step2：接続待ち→逐次実行→fetch/batch

接続待ちが支配的なら、プール枯渇の原因を潰し、同時実行数とプールの整合を取ります。

待ちが出る場合は、単にプールを増やす前に、リークや長時間トランザクションの有無を確認します。

合わせて、リークや長時間トランザクションがないかを点検すると再発防止になります。

逐次実行が支配的なら、一括取得とバッチ更新で往復を減らします。

ここは改善幅が大きいので、最初に手を付ける価値が高いです。

一括化は、処理単位を大きくしすぎないように、分割サイズの上限を決めて進めます。

結果取得が支配的なら、fetchSizeやページングで転送を整えます。

同時に、必要列の削減やDTO最小化で変換CPUも落とせる場合があります。

fetchSizeの調整は、メモリ消費とレイテンシの両方を観測しながら段階的に行います。

Step3：ORMのSQL制御→SQL/インデックス最適化

ORM起因なら、発行SQLを制御してN+1や不要取得を止めます。

ログで「どの操作が何回出しているか」を押さえると、修正箇所が絞れます。

ORMの改善は、読み取りと更新で方針を分けると、保守性を保ちながら効かせやすいです。

SQL起因なら、実行計画とインデックス、取得件数の削減を優先します。

アプリ側の変更よりもDB側の変更が効く場合もあるため、両面で評価します。

変更は一度にまとめず、1回の変更で1つの仮説を検証する形にすると原因が追いやすいです。

必要ならアプリ設計とDB設計の両面で、ボトルネックを再配置します。

最後は「全体最適」として、処理の責務をどこに置くかも含めて調整します。

最終確認として、代表的な負荷条件でスループットとレイテンシが安定するかを見ます。

よくある質問（Q & A）

最後に、現場で判断に迷いやすい質問をまとめます。

ここを読むだけでも、改善の方針が立つように要点を絞ります。

短い答えだけでなく、条件付きの見方も添えます。

条件が書けると、状況に合わせて判断しやすくなります。

加えて、判断を急ぐときでも「まず計測」に戻れるようにしておきます。

EJBをJDBCに変えるだけで速くなりますか？

効くのは、境界越えのオーバーヘッドや余計な往復が支配的なときです。

一方で、移行の効果は「どの層が支配的か」に強く依存します。

SQLやDB側が原因のときは、JDBCにしても改善幅は限定的です。

まず計測して、EJB経由の付随時間が大きいかを確認します。

付随時間が小さいなら、移行よりもSQLや接続待ちの解消を優先します。

移行するなら、性能が必要な経路だけを対象にし、段階的に広げるのが安全です。

ORMは使わない方がよいですか？

使わない方がよいのではなく、発行SQLを制御できる範囲で使うのが現実的です。

ORMは開発速度と保守性に強みがあるため、性能が要求される経路だけ最適化する発想が合います。

読み取りと更新で戦略を分け、性能が要求される経路だけ最適化する方が保守性も保てます。

SQLログと実行回数を見ながら、最適化の対象を狭めると安全です。

結論としては、ORMを捨てるより「見える化して制御する」方が成果につながりやすいです。

Java側の遅さはどう調べればよいですか？

まずSQLログと実行時間に加えて、接続取得待ちを分けて計測します。

次にAPMかプロファイラで、変換やシリアライズの時間が支配的かを確認します。

最後にDB側統計で、実行回数が多いSQLや待機イベントが支配的かを確認します。

3方向から同じ結論が出ると、対策がブレにくくなります。

調査の途中で数字が矛盾する場合は、計測範囲の定義が混ざっていないかを疑います。

fetchSize/batchSizeの目安はありますか？

目安は「往復回数が減るか」と「メモリが持つか」のバランスで決めます。

小さく始めて段階的に上げ、件数とレイテンシが安定する点を探します。

一気に大きく変えるより、変化幅を固定して検証した方が原因が追いやすいです。

値を上げた結果、GCやタイムアウトが増えるなら、別の制約が支配的になっています。

接続プールは何を基準に決めればよいですか？

待ち時間が発生しない範囲で、同時実行数とDB接続上限の間に収めます。

ピーク時のメトリクスを見て、待ちが出ているなら原因を分解してから調整します。

単に増やすのではなく、待ちが出る理由を潰すと、少ない接続数でも安定します。

最終的には、プールの待ち時間が常時ゼロに近い状態を目標にします。

まとめ

JavaのSQL性能改善は、SQLだけを疑うのではなく、接続待ち、往復回数、変換処理を含めて切り分けるのが近道です。

最初に計測ログ4点を揃え、効果の大きい順に対策すると、短期間で体感が変わります。

改善の最中は、条件を固定して前後比較し、改善が効いた理由を言語化します。

改善後は再現条件を固定した前後比較を残し、同じ遅さが再発しない状態にします。

さらに、ログとメトリクスを継続的に監視し、遅さの兆候を早期に検知できるようにします。

最終的には、ログとメトリクスが揃った状態を維持し、遅さが出たときにすぐ切り分けできる運用にします。