最終更新日：2026年8月24日
fe fe-technology database computer-system
まず結論
データベースの性能低下を調べるときは、原因ごとに「何を確認すれば、その原因を直接確かめられるか」を対応付けることが大切です。
基本情報技術者試験では、次の4つを切り分けられると判断しやすくなります。
| 想定原因 | まず調べるもの |
|---|---|
| 重いSQL | 遅い処理、実行時間 |
| 他システムや利用者増加による負荷 | 外的要因、通信量、システム負荷 |
| データベースバッファ不足 | キャッシュやバッファのヒット率 |
| フラグメンテーション | データの格納状況、断片化の状態 |
試験では、調査項目の名前を丸暗記するより、
原因は何？
↓
その原因を直接確認できるものは何？
と考えると選択肢を切りやすくなります。
直感的な説明
データベースの応答が遅くなったとき、原因は1つとは限りません。
例えば、同じ「遅い」という症状でも、次のように原因が違います。
SQLそのものが重い
→ 処理に時間がかかる
アクセスが急に増えた
→ サーバや通信が混雑する
メモリ上に必要なデータが残らない
→ ディスクを読む回数が増える
データがばらばらに格納されている
→ ディスクI/Oが増える
つまり、症状だけでは原因を決められません。
そこで、原因ごとに確認する場所を変える必要があります。
イメージとしては、機械の故障診断と同じです。
振動が大きい
→ 回転部を調べる
油圧が低い
→ ポンプや漏れを調べる
温度が高い
→ 冷却や負荷を調べる
データベースでも、原因に合った測定項目を選ぶことが重要です。
定義・仕組み
1. 重いSQL
SQL文そのものに時間がかかっている場合は、どの処理が遅いかを確認します。
例えば、
- 大量データを全件検索している
- 結合条件が不適切
- 不要な並べ替えをしている
- インデックスを有効に使えていない
といった場合です。
このときに見るべきなのは、
どのSQLが遅いか
どの処理に時間がかかっているか
です。
したがって、原因と調査項目の対応は次のようになります。
重いSQL
→ 遅い処理の特定
2. 外部負荷の増加
アプリケーションを変更していなくても、周囲の状況が変われば性能は低下します。
例えば、
- 同じサーバ上に別システムが追加された
- 利用者数が増えた
- 通信量が増えた
- 他の処理がCPUやディスクを多く使っている
といったケースです。
この場合は、データベース内部だけを見るのではなく、外部要因の変化を確認します。
他システムの負荷
利用者数
通信量
CPU使用率
ディスク負荷
などを確認します。
3. データベースバッファ不足
データベースは、よく使うデータを主記憶上のバッファに保持して、毎回ディスクを読まなくてもよいようにします。
必要なデータがバッファにある
→ メモリから読める
→ 速い
必要なデータがバッファにない
→ ディスクから読む
→ 遅くなりやすい
このとき役立つのがヒット率です。
ヒット率は、必要なデータをメモリ上で見つけられた割合を表します。
ヒット率が高い
→ メモリ上で処理できる割合が高い
ヒット率が低い
→ ディスクアクセスが増えやすい
したがって、
データベースバッファ不足
→ キャッシュ・バッファのヒット率
と対応付けます。
4. フラグメンテーション
フラグメンテーションとは、データや空き領域が連続せず、ばらばらに配置された状態です。
簡単に表すと、次のようなイメージです。
連続している状態
[データ][データ][データ][空き][空き]
断片化している状態
[データ][空き][データ][別データ][データ]
データが複数の場所に分かれていると、読み書きのために複数箇所へアクセスする必要があり、ディスクI/Oが増えることがあります。
そのため、フラグメンテーションが疑われるときに確認するのは、データの格納状況や断片化の状態です。
フラグメンテーション
→ データの格納状況を確認
このテーマは、基本情報技術者試験の「データベース」「コンピュータ構成要素」「性能評価」と関係する内容です。公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。
科目Aでどう出る？
科目Aでは、原因と調査項目の組合せを選ばせる問題があります。
このタイプは、調査項目の名前だけを見ずに、原因と直接つながっているかを確認します。
判断表
| 原因 | 判断するキーワード | 選びやすい調査項目 |
|---|---|---|
| SQLが重い | SQL、処理時間、検索、実行 | 遅い処理の特定 |
| 他システムや利用者増加 | 負荷、通信量、利用者数、共有サーバ | 外的要因の変化 |
| バッファ不足 | メモリ、キャッシュ、主記憶 | ヒット率 |
| フラグメンテーション | 断片化、格納位置、ディスクI/O | データの格納状況 |
試験中の切り分け手順
① 原因の種類を決める
② CPU・メモリ・ディスク・SQL・外部負荷のどれかに分類する
③ その原因を直接測れる調査項目を選ぶ
例えば、フラグメンテーションが原因なら、最初に考えるべきなのはキャッシュヒット率ではありません。
フラグメンテーション
→ ディスク上の配置の問題
→ 格納状況を見る
一方、バッファ不足なら、
バッファ不足
→ メモリ上に必要データが残らない
→ ヒット率を見る
と考えます。
「結果」と「原因」を混同しない
ここも重要です。
ディスクI/Oが多い
というのは、原因そのものではなく、複数の原因から起こる結果であることがあります。
例えば、
バッファ不足
→ ディスクアクセス増加
フラグメンテーション
→ ディスクアクセス増加
の両方が考えられます。
そのため、I/Oが多いだけでは原因を決めず、どこに問題があるかをさらに切り分けることが大切です。
どんな場面で使う？
性能劣化の原因調査
アプリケーションを変更していないのに応答時間が悪化した場合、次のように原因を広く確認します。
外部負荷は増えていないか
SQLは重くなっていないか
メモリは足りているか
ディスク上の格納状態は悪化していないか
データベース運用
長期間データの追加・更新・削除を繰り返すシステムでは、データ量や格納状況が変化します。
また、利用者数の増加や他システムの追加など、アプリケーションそのものを変更しなくても性能条件は変化します。
そのため、定期的な性能監視では、
- SQL実行時間
- CPU・メモリ使用率
- ディスクI/O
- バッファヒット率
- データやインデックスの格納状態
などを組み合わせて確認します。
よくある誤解・混同
フラグメンテーションならキャッシュヒット率を見る？
違います。
キャッシュヒット率
→ メモリ上に必要データがあるか
フラグメンテーション
→ ディスク上の格納状態
です。
フラグメンテーションを疑うなら、格納状況や断片化の状態を確認します。
DBバッファ不足とディスク容量不足は同じ？
違います。
DBバッファ不足
→ 主記憶上の作業領域が足りない
ディスク容量不足
→ 保存領域そのものが足りない
バッファ不足では、ヒット率やメモリ利用状況が判断材料になります。
重いSQLなら外部負荷を調べればよい？
まずはSQLそのものを確認します。
重いSQLが原因
→ どのSQL・処理が遅いかを特定
一方で、利用者数増加や共有サーバの負荷が疑われるなら外部要因を調べます。
フラグメンテーションは「空き容量が少ないこと」？
必ずしも同じではありません。
空き領域があっても、それが細かく分散していれば断片化は起こります。
空き容量の総量
と、
どのように配置されているか
は別の問題です。
インデックスとフラグメンテーションは同じ？
違います。
インデックスは、データを効率よく検索するための索引です。
フラグメンテーションは、データや空き領域が分散して格納される状態です。
ただし、DBMSによってはインデックス自体の断片化が性能へ影響することもあります。FE試験では、まず「検索を速くする仕組み」と「格納状態の問題」を分けて考えます。
まとめ（試験直前用）
- 性能低下は、症状だけでなく原因ごとに調査項目を変える
- 重いSQL → 遅い処理を特定する
- 外部負荷の増加 → 利用者数、通信量、共有サーバ負荷などを確認する
- DBバッファ不足 → キャッシュ・バッファのヒット率を見る
- フラグメンテーション → データの格納状況、断片化の状態を見る
- 「I/Oが多い」は結果の場合があるので、原因まで切り分ける
原因
↓
その原因を直接確認できる調査項目
この順番で考えると、性能調査の組合せ問題を切り分けやすくなります。