本番環境でインデックス再構築を行うことになりました。
事前に対象のインデックスを確認したところ、
一度も使われていないインデックスだったのです...
データベースのインデックスの断片化を監視し、
再構築する仕組みを作っていました。
本稼働後、初めてインデックス断片化の条件に合致し、
アプリチームが作成した仕組みを利用し、インデックスを再構築することになりました。
この時、関係者で打合せを行い、
エラーになったら、インデックスを手動で再構築するのでは無く、
作業前の状態に戻してください、と言われていました。
本番環境へアクセスするには申請が必要で、普段アクセスできないようになっています。
また、性能については難しく、分かる人がいません。
という理由があり、再構築しようとしている
インデックスを確認すると、次のような状態でした。
・pg_stat_user_indexes.idx_scan：0
・avg_leaf_density：50を少し下回っている（半分以上が虫食い状態）
つまり、
・一度も検索で使われていない
・それなのに断片化している
という状態でした。（関連記事参照）
インデックスは検索処理を高速化しますが、
INSERT・UPDATE・DELETE など、
インデックスを更新する処理では オーバーヘッドになります。
インデックスを再構築するより、
まず、本当に必要なインデックスかを見直すべきです。
性能問題は、
「再構築すること」が目的ではありません。
「本当にそのインデックスが必要なのか」
まで確認することが重要だと痛感しました。
このような状況になった要因として、次のようなことが考えられます。
・インデックスの設計を基本設計の段階で行っており、その後見直していない
・性能テストで確認していない
・本稼働後、確認していない
関連記事
- データベース(PostgreSQL)のINDEX再構築の目安
- PostgreSQLでシステムテスト以降で性能を改善する監視すべきポイント その１
- PostgreSQLでシステムテスト以降で性能を改善する監視すべきポイント その２
- 【PostgreSQL】INDEXが効かない原因７選（実務でハマる落とし穴）
- PostgreSQLのインデックス再構築運用（断片化監視と実務での対応）
補足（より深く学びたい方へ）
PostgreSQLの性能調査を体系的に学びたい方は
今回のような「不要なインデックスの見極め」を含め、
実務で役立つ性能分析・チューニングの進め方を講座で体系的に解説しています。
※現在Udemyセール中のため、通常より安く受講できます。
残り 1日です。