インデックスは「作って終わり」ではない
多くのDBAが新人時代に教わるのは「遅いクエリにはインデックスを貼れ」という定石です。しかし、実務経験を積むと、インデックスは「貼れば貼るほど書き込み性能が劣化する」という副作用に直面します。今回は、作成だけでなく、不要なインデックスの削除と、変化するワークロードへの適応に焦点を当てます。
削除の判断基準は「統計情報」から導く
インデックスを削除する際、最も怖いのは「誰が使っているか分からない」という恐怖です。PostgreSQLのpg_stat_user_indexesやSQL Serverのsys.dm_db_index_usage_statsなどを活用し、「スキャン回数がゼロ、または極端に少ない」インデックスを特定します。
ただし、注意すべきは「月次バッチ」の存在です。日常的なOLTP処理では使われなくても、月末の集計処理でのみフル活用されるケースがあります。削除前には必ず、最低でも1ヶ月以上の統計期間を確保し、かつクエリログと照らし合わせるのが鉄則です。
インデックスの変更：再構築か、新設か
インデックスの断片化（フラグメンテーション）が起きた際、安易な再構築（REBUILD）を実行していませんか。最近のデータベースでは、オンラインでのインデックス作成（CREATE INDEX CONCURRENTLYなど）が一般的です。
特筆すべきは、「複合インデックスの順序見直し」です。例えば、WHERE句の条件が完全一致（=）から範囲検索（BETWEEN）へ変わった場合、インデックスの左端の列を変えるだけで劇的な改善が見込めます。単なる再構築で物理的な整理を行う前に、クエリの検索条件の変化に合わせて「インデックスの構成そのもの」を再定義できないか検討してください。
DBAが守るべき「インデックスの最小主義」
私の現場では、インデックスを新規作成する際、必ず「そのインデックスが削除されるべき条件」をドキュメントに残すようにしています。例えば「このテーブルのデータが100万件を超えたら不要になる」「別の検索機能が実装されたら削除する」といったライフサイクル管理です。
インデックスは、データベースという「図書館」の目次です。目次が本の内容よりも分厚くなっては本末転倒です。「足す技術」よりも「削る勇気」を持つことこそが、長期的なデータベースの健全性を保つ唯一の道だと確信しています。
コメント