主要なエンティティのインデックス設計が適切か？¶
Type: Structure
Category: データ
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
インデックスは検索性能の鍵だが、安易な追加はパフォーマンス悪化やストレージ肥大化の原因にもなる。アクセスパターンに基づく慎重な設計が必要
例¶
- 検索条件に使われるカラムにインデックス付与（例：user_uuid, created_at）
- 結合キーに複合インデックスを設定（例：tenant_id, status）
- 頻繁に範囲検索される日付系のカラムにインデックスを付与
よくある失敗例¶
- インデックスをつけすぎてINSERT/UPDATEが遅くなる
- ユースケースに対して不要な複合インデックスを追加
- クエリの書き方によりインデックスが効かずフルスキャンが発生
FAQ¶
Q. 現時点で必要かわからないけどインデックスはつけるべき？
A. 想定されるユースケースがあるなら事前設計してよいが、安易な予防的インデックス追加は書き込み性能やストレージに悪影響を与えるため、実運用に基づいた見直しが必要
Q. 単独インデックスと複合インデックス、どちらを使う？あと複合インデックスはどうやって順番を決める？
A. 両方あると冗長になるケースが多い。実行クエリに合わせて使い分け、必要なものだけに限定するのが無難。複合インデックスの順番はフィルタ条件でよく使われるカラムを先頭に、ソート順に使うカラムは後ろに置くのが基本だが、explain analyzeによる実行計画の分析もして判断すべき