【要約】【PostgreSQL】複合インデックスを利用したパフォーマンス改善事例 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
- ・2300万件のデータに対し、特定の条件絞り込みとソートを含むクエリが約75秒を要した。
- ・key_columnに単一インデックスがあるが、プランナがid(PK)を優先して使用。
- ・id順に全件走査し、一行ずつ条件判定を行うため、初回ヒットに膨大な時間を要した。
- ・DB高負荷によるアラート頻発が深刻な課題となっていた。
// Approach
1.
EXPLAIN (ANALYZE, BUFFERS, VERBOSE) を用い、実行計画を詳細に解析。2.プランナが「ソートコストの回避」を優先し、idインデックスによる走査を選択している事実を特定。
3.絞り込みとソートを同時に満たす複合インデックスを設計。
4.
CREATE INDEX sample_table_key_column_id ON sample_table (key_column, id); を実行。5.左側に等価制約（絞り込み条件）を配置する設計原則を適用。
// Result
- ・実行時間が約75秒から約1.4ミリ秒へ劇的に改善。
- ・実行計画が
FilterからIndex Condへ変化。 - ・インデックスによる高速な絞り込みと、ソート不要なデータ取得を両立した。
Senior Engineer Insight
> 単一インデックスの存在が最適解を保証するわけではない。プランナが「ソート回避」を優先する特性を理解することが不可欠である。実行計画における
Filter と Index Cond の差は、チューニングの生命線といえる。大規模環境では、複合インデックスによる改善に加え、OFFSET を避けるキーセットページネーションへの設計変更も併せて検討すべきである。