django-index-design

Django のインデックス設計

このスキルは、プロファイリングによって特定のクエリがインデックスの恩恵を受けると確認できた場合にのみ、インデックスを追加または変更するために使用します。インデックスは対象となる読み取りや制約を高速化しますが、書き込みコスト、マイグレーションのリスク、保守の負担も増加します。

ワークフロー

1. クエリプランから始めます。

   • SQL、フィルター、結合、並び順、選択する列、テーブルサイズ、現在のインデックスを記録します。
   • 最適化するだけの重要性がそのクエリにあることを確認します。

2. インデックスの形状を選択します。

   • 等価条件のフィルターを先にし、その後に必要に応じて範囲や並び順のフィールドを指定します。
   • 可能であれば、LIMIT クエリの ORDER BY に合わせます。
   • 頻繁にクエリされるサブセットには部分インデックスを使用します。
   • 選択する列が安定しており、インデックスのみのスキャンが見込める場合に限り、カバリングインデックスを使用します。
   • JSONB の包含、配列、全文検索パターンには GIN を使用します。B-tree でこれらを解決できるとは考えないでください。

3. Django のモデルまたはマイグレーションでインデックスを定義します。

   • 通常のモデル所有インデックスには Meta.indexes を優先します。
   • 稼働中の PostgreSQL テーブルには AddIndexConcurrently と RemoveIndexConcurrently を優先します。
   • Django でインデックスを表現できない場合に限り、生の SQL を使用します。

4. 本番環境に近いデータで検証します。

   • QuerySet.explain() または EXPLAIN ANALYZE を再実行します。
   • プランナーが対象のクエリにインデックスを使用することを確認します。
   • インデックスを追加するテーブルの書き込みが多い場合は、書き込み経路への影響を確認します。

インデックスの例とマイグレーションのテンプレートについては、index-patterns.md を参照してください。

本番環境でのルール

• PostgreSQL の稼働中テーブルでは、並行インデックス操作を使用し、マイグレーションで atomic = False を設定します。
• 名前は短く、安定していて、明確なものにします。
• 一意制約または左端の列を共有する複合インデックスで既にカバーされている重複インデックスは追加しないでください。
• 未使用のインデックスを削除するのは、本番環境での使用状況とデプロイのロールバック要件を確認してからにしてください。

検証

変更前後のプランの根拠、正確なマイグレーション操作、ロック、書き込み、ロールバックに関する運用リスクの評価を示して完了します。