データベースのパフォーマンスを考えよう｜SQLが遅くなる理由と改善の基本

はじめに

Webアプリを作っていると、
必ずこんな場面に出会います。

• 「SQLが遅い」
• 「画面表示が重い」
• 「データが増えたら急に遅くなった」

このときに、

「とりあえずサーバーを強くする」

という判断をすると、
コストも技術力も伸びません。

この記事では、

なぜデータベースは遅くなるのか？
Webエンジニアが最低限知っておくべき
パフォーマンス改善の考え方

を、初心者向けに解説します。

データベースのパフォーマンスとは？

データベースのパフォーマンスとは、

データを
どれだけ速く・効率よく
取得・更新できるか

という指標です。

特にWebでは、

• SELECTの速度
• レスポンス時間

が
体感速度に直結します。

なぜSQLは遅くなるのか？

SQLが遅くなる原因は、
主に次の4つです。

1. データ量が多い
2. 検索条件が悪い
3. インデックスがない
4. SQLの書き方が悪い

データ量が増えると何が起きる？

データが少ないうちは、

• 全件検索
• SELECT *

でも
問題になりません。

しかしデータが増えると、

全件スキャン＝致命傷

になります。

👉
「最初は速い」は当てになりません。

インデックスとは何か？

インデックスとは一言でいうと、

データベースの索引（目次）

です。

本に例えると、

• インデックスなし：最初から読む
• インデックスあり：目次から探す

👉
検索速度が段違いになります。

インデックスが効く仕組み（イメージ）

• WHERE句で使われるカラム
• JOINで使われるカラム

に
インデックスがあると、

必要な行だけを
一気に探し出せる

ようになります。

インデックスの注意点

インデックスは万能ではありません。

• 追加すると
  • 検索は速くなる
  • 更新は遅くなる

👉
読み取りと書き込みのトレードオフです。

インデックスを張るべき典型例

• 主キー
• 外部キー
• WHERE句で頻繁に使うカラム
• JOIN条件に使うカラム

👉
「よく探すもの」に張るのが基本です。

悪いSQLの例

初心者がやりがちです。

SELECT * FROM users;

• 不要なカラムまで取得
• ネットワーク負荷増
• メモリ消費増

👉
必要なものだけ取るのが基本です。

良いSQLの例

SELECT id, name FROM users WHERE status = 'active';

• カラムを限定
• 条件で絞る

👉
速く・軽いSQLです。

EXPLAINとは何か？（概要）

EXPLAINとは、

SQLが
どのように実行されるかを
確認するための仕組み

です。

• インデックスが使われているか
• 全件スキャンしていないか

を
確認できます。

👉
詳細は中級編でOKです。

N+1問題とは何か？

Laravelで
特に有名なのが
N+1問題です。

• 1回の取得
• ループ内でさらにSQL

👉
SQLが爆発的に増える問題です。

N+1問題の本質

N+1問題の本質は、

「意図せずSQLを大量に発行している」

という点です。

N+1問題の基本的な対策

Laravelでは、

• eager loading
• with()

を使います。

👉
SQLをまとめて発行します。

パフォーマンス改善の優先順位

重要です。

1. SQL・設計を見直す
2. インデックスを追加
3. キャッシュを使う
4. 最後にサーバー強化

👉
いきなり4はNGです。

Webエンジニアが持つべき視点

Webエンジニアとしては、

• SQLは軽いか？
• データ量は増えたらどうなる？
• 同じ処理を何度もしていないか？

👉
「将来」を想像する力が重要です。

LaravelとDBパフォーマンス

Laravelでは、

• Eloquentの使い方
• chunk / cursor
• eager loading

で
パフォーマンスが
大きく変わります。

👉
フレームワーク任せは危険です。

初心者が押さえるべきポイント

この段階では、

• インデックスは索引
• SELECT * は避ける
• N+1問題を知っている

これが分かっていればOKです。

次に学ぶべきこと

ここまで来たら、
データベース基礎の子記事はすべて完了です 🎉

まとめ

• DBパフォーマンスはSQL次第
• インデックスが鍵
• N+1問題は頻出
• 改善は下から積み上げる

この記事は
DB基礎の締めです。