【要約】RailsとDBインデックス 〜なぜ index があると速いのか〜 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がデータ量の増加に伴うクエリの低速化に直面する問題について述べている。適切な設計が行われない場合、以下のような課題が発生する。
- ・インデックス未設定によるフルテーブルスキャン（O(n)）の発生。
- ・「とりあえず全部に貼る」設計による、書き込み（INSERT/UPDATE）性能の低下とストレージの圧迫。
- ・カーディナリティが低い列や中間一致LIKE検索など、インデックスが効かない条件による意図しない全走査。
- ・JOIN時のNested Loopにおいて、内側テーブルにインデックスがないことによる計算量の爆発（O(n×m)）。
// Approach
著者は、B-treeの特性を理解した上での論理的なインデックス設計と、実行計画による検証プロセスを提案している。具体的な手法は以下の通りである。
- ・B-treeの構造を利用し、範囲検索やソートにも対応可能な検索効率（O(log n)）を確保する。
- ・「よく検索する × 絞り込める（高カーディナリティ）」列を優先的にインデックス対象とする。
- ・複合インデックスでは、検索条件の左側に重要な列を配置する「左端一致の原則」を遵守する。
- ・EXPLAINまたはEXPLAIN ANALYZEを用い、Seq ScanやNested Loopのループ回数を実測して効能を確認する。
// Result
適切なインデックス設計により、データ量が増大しても検索性能を極めて低コストに維持できる。記事内の比較では、以下の定量的な効果が示されている。
- ・100万件のデータに対し、検索ステップを最大100万回から約20回へ削減。
- ・データが10億件に増えても、検索ステップはわずか30回程度に抑制。
- ・実行計画の可視化により、JOIN時のボトルネック（loops数が多いSeq Scan）を特定可能になる。
Senior Engineer Insight
> インデックスは万能薬ではなく、書き込みコストとのトレードオフである。大規模トラフィックを扱う現場では、単に「速くなる」という理解ではなく、カーディナリティや更新頻度を考慮した「引き算の設計」が求められる。また、AIが生成するSQLは構文的に正しくても、実行計画が致命的なフルスキャンになるリスクがある。EXPLAINを読み解き、loops数やスキャン方式を監視する習慣こそが、スケーラビリティを担保するエンジニアの分水嶺となる。