⚠️

インデックスは万能じゃない！DB高速化の落とし穴

に公開
SQL
Database
performance
index
zennfes2025infra
tech

概要

データベースの性能改善といえば「インデックス」。
検索速度を劇的に速くしてくれる魔法の仕組みに思えますが、実は使いどころを間違えると逆に性能を落としてしまうこともあります。
この記事では インデックスの理論と落とし穴 を、図解を交えて整理します。

インデックスとは？

インデックスは本の「索引」のようなものです。
テーブル全体を順番に探すのではなく、キーから効率的に目的の行を見つけられるようにする仕組みです。

全件スキャン（インデックスなし）

インデックスがない場合、テーブル全体を順番にチェックする「全件スキャン」が発生します。
データが増えるほど検索時間は長くなります。

インデックス検索（B-Tree）

B-Tree などの構造を辿って直接目的レコードにアクセスするため、高速に検索できます。

インデックスのメリット

読み取り中心のアプリ（ECサイトの商品検索など）では、インデックスは非常に強力です。

  • 検索が高速化する
  • 絞り込み・JOIN・ソートが効率化する
  • 大規模データでも応答時間を一定に保てる

インデックスのデメリット

一方で、インデックスには隠れたコストがあります。

INSERT（インデックスなし）

インデックスなしでは、追加処理だけで済むため高速です。

INSERT（インデックスあり）

インデックスがあると、追加・更新ごとに B-Tree の再構築が必要になり、処理が重くなります。

書き込みにおけるデメリット

  • INSERT/UPDATE/DELETE が遅くなる
  • インデックスが多いほど負荷が増える
  • 一部のクエリではインデックスが効かない場合がある（例：LIKE '%xxx'）

アプリ特性とインデックス戦略

アプリの性質によって、インデックスの貼り方は変わります。

  • 読み取り主体（検索が多い） → インデックスを積極的に貼る
  • 登録主体（書き込みが多い） → 必要最小限のインデックスに絞る

実際に試すSQL例

インデックスなし検索

実行計画：全件スキャン（Seq Scan）

EXPLAIN SELECT * FROM users WHERE email = 'foo@example.com';

インデックスあり検索

実行計画：Index Scan → 高速化

CREATE INDEX idx_users_email ON users(email);
EXPLAIN SELECT * FROM users WHERE email = 'foo@example.com';

実際に EXPLAIN を試すことで、インデックスの有無による検索効率の違いを確認できます。

まとめ

インデックスは「魔法の高速化ツール」ではなく「諸刃の剣」です。
アプリの特性を見極めて、正しく使いこなしていきましょう。

  • インデックスは検索を高速化する強力な仕組み
  • ただし書き込み性能に影響することもある
  • 登録主体アプリでは「貼りすぎ」は逆効果
  • 最小限で始め、必要になったら追加するのがベストプラクティス!

Discussion