データベース（PostgreSQL）のインデックスは 徐々に断片化していきます。
しかし、実務では「いつ・どのように再構築するか」
の運用まで設計されていないことが多いです。
本記事では、実際のプロジェクトで行っていた
インデックス再構築の運用について紹介します。
クラスタ環境を使用しており、以下のように運用していた。
インデックス断片化の監視方法
INDEXの状態確認は負荷が高いため、以下のように実施。
■監視のポイント
①スタンバイ側で実行（負荷軽減のため）
②全インデックスを分割してチェック
例：70個なら1日10個ずつ
③断片化の条件を満たしたらログ出力
→Zabbixで監視し、通知
【補足】
①INDEXの状態は、プライマリとスタンバイの2台で同じ。
プライマリ側とスタンバイ側の双方で実行し、プライマリだったら即時終了。
プライマリとスタンバイが切り替わる可能性があるため、双方で実行。
②全INDEXのサイズを確認し、サイズで7等分する。
各INDEXを週に1回ずつ実行し、毎日実行。
■断片化の判断
・平均密度が50%超～70%
・50%前後
→再構築が難しい環境、アクセス頻度が低い場合 [※2]
・70%前後
→再構築しやすい環境、アクセス頻度が高い場合 [※2]
・サイズが50～100MB以上
上記の平均密度参照
平均密度とサイズをAND条件で判断
[※2] アクセス頻度は pg_stat_user_indexes.idx_scanで累計回数を確認可能
インデックス再構築の方法
インデックス再構築はプライマリで実行します。
そのため、スタンバイで断片化状態のファイルを確認し、
対象インデックスを特定した後、
スタンバイからプライマリへ接続して再構築を実施。
運用で重要なポイント
インデックスの断片化は必ず発生します。
そのため、本稼働前に運用として組み込んでおくことが重要です。
後から対応しようとしても、予算や調整の都合で難しい場合が多いです。
実際の効果（再構築前後の比較）
システムテスト時、INDEX再構築のテストを行ったが、以下になった。
※私はインフラ担当だったが、INDEXが断片化していても誰も気付かない。
これだけ断片化していたら、さすがに遅くなっている筈。
■再構築前後のサイズ比較
再構築前
・テーブル：62MB
・インデックス：600MB
再構築後
・インデックス：75MB
→約8分の1に削減
補足（より深く学びたい方へ）
今回のような「性能問題の原因分析」やチューニングの具体的な
手順について、講座で体系的に解説しています。
URL：https://www.udemy.com/course/postgresql-sql/?referralCode=64B372729B6BC0073ACB