インデックスはなぜ万能ではないのか（応用情報視点）

データベースの性能改善というと、
「とりあえずインデックスを貼る」という対応が
真っ先に思い浮かぶことがあります。

応用情報技術者試験でも、
インデックスは重要なテーマですが、
万能な解決策ではないことを前提に出題されます。

この回では、
なぜインデックスが万能ではないのかを、
応用情報視点で整理します。

インデックスが解決している問題

インデックスは、
検索を速くするための仕組みです。

• 条件に合う行を素早く見つける
• 全件走査を避ける
• 検索系のレスポンスを改善する

この点だけを見ると、
「付ければ付けるほど良さそう」に見えます。

それでも万能にならない理由

インデックスには、
必ずコストが伴います。

• 更新時にインデックスも更新される
• INSERT / UPDATE / DELETE が遅くなる
• ストレージを消費する

応用情報では、
速くなる場面と遅くなる場面がある
という前提を理解しているかが問われます。

応用情報でよく出る勘違い

午後問題では、

• 検索が遅い → インデックス追加
• それでも改善しない

という流れが描かれることがあります。

原因が、

• 条件に合わない列に貼っている
• 更新頻度が高すぎる
• そもそも設計が歪んでいる

といった点にあることを
見抜かせる構造です。

インデックス以前の問題

応用情報では、
次のような視点も重視されます。

• テーブル設計は適切か
• 正規化・非正規化の判断は妥当か
• アクセスパターンは整理されているか

インデックスは、
設計の代わりにはならない
という前提が重要です。

実務でも起きやすい失敗

実務でも、

• インデックスを増やしすぎて更新が重い
• どのインデックスが効いているか分からない
• 目的のないインデックスが残り続ける

といった問題が起きがちです。

応用情報は、
その失敗を避けるための
思考の順序を示しています。

まとめ

• インデックスは検索を速くする仕組み
• 追加には必ずコストがある
• 応用情報は前提条件と使いどころを問う

性能問題を見るときは、
「何を速くしたいのか」を
先に言葉にすることが重要です。

次回予告

次回は、
「トランザクションは何を守っているのか」
を扱います。

データの整合性の話に進みます。