django-query-plan-reading

Django クエリプランの読み方

特定の SQL 文またはクエリセットが処理コストの大部分を占めている場合に、このスキルを使用します。ORM コードから推測するのではなく、データベースが処理に時間をかけている理由を説明することが目的です。

ワークフロー

1. 正確なクエリを取得します。

   • そのクエリを生成したクエリセットを優先します。
   • ログに記録された SQL から始める場合は、バインドされたパラメーター、または代表的なリテラル値を含めます。

2. プランを生成します。

   • ORM が管理する SQL には queryset.explain() を使用します。
   • 生の SQL、ビュー、マテリアライズドビュー、またはログからコピーした SQL には、データベースの EXPLAIN を使用します。
   • データベースがクエリを実行するため、安全な環境でのみ analyze=True を使用します。

3. 最も深いノードから外側に向かって読みます。

   • テーブルスキャン、インデックススキャン、結合、ソート、集約、制限を特定します。
   • analyze を使用する場合は、推定行数と実際の行数を比較します。
   • 後続のノードに多数の行を渡す高コストなノードを探します。

4. 次に行う変更を決めます。

   • 選択性の高いアクセス経路がない場合：django-index-design を使用します。
   • クエリの形状が有用なインデックスアクセスを妨げている場合：フィルター、並べ替え、または結合方法を書き換えます。
   • 避けられない大規模な集約の場合：django-db-side-computation または django-materialized-views を検討します。
   • 深いオフセットによるコストの場合：django-pagination-performance を使用します。

5. 変更後、同じプランを再実行します。

   • スキャンの種類、行数、ソートノード、ヒープフェッチ数、バッファー、計画時間、実行時間を比較します。

プランの読み取り方や変更前後のレビューに関するメモは、explain-checklist.md を参照してください。

安全に関する注意事項

• EXPLAIN ANALYZE はクエリを実行します。影響を把握していない限り、更新処理、安全でない関数、本番環境の処理には使用しないでください。
• シーケンシャルスキャンが必ずしも悪いとは限りません。テーブルが小さい場合や、述語がテーブルの大部分に一致する場合は、最適なことがあります。
• インデックスが使用されていても、必ずしも良いとは限りません。ランダムなヒープアクセス、不適切なカーディナリティ推定、またはインデックス適用後のソートが、依然としてパフォーマンスを支配することがあります。

検証

変更前後のプランの抜粋を示し、どのノードが変わったのか、またその変更が重要な理由を平易に説明して仕上げます。