ルール
避ける 冗長な データベース インデックス。
重複する データベース インデックス 無駄にする
ストレージ そして 遅くする ～ 書き込み。
対応言語： SQLはじめに
不要なインデックスは、複数のインデックスが同じ列をカバーしている場合、またはあるインデックスが別のインデックスのプレフィックスである場合に発生します。すべてのインデックスはディスク領域を消費し、INSERT、UPDATE、DELETE操作時に更新される必要があります。類似の列に5つの重複するインデックスを持つテーブルは、読み取り最適化には1つのインデックスで十分であるにもかかわらず、書き込みパフォーマンスのペナルティを5回支払うことになります。
なぜ重要なのか
パフォーマンスへの影響： データが変更されるとデータベースがすべてのインデックスを更新する必要があるため、すべてのインデックスは書き込み操作を遅くします。冗長なインデックスは、クエリのメリットを提供することなくこのコストを増大させます。3つの冗長なインデックスを持つテーブルは user_id 常に1つのインデックスしか使用されないにもかかわらず、書き込みオーバーヘッドを3倍にします。
ストレージコスト: インデックスは、インデックス化されたカラムサイズと行数に比例してディスクスペースを消費します。冗長なインデックスは、実際のデータや有用なインデックスに利用できるストレージを浪費します。不要なインデックスを持つ大規模なテーブルは、ギガバイト単位のストレージを無駄にする可能性があります。
メンテナンスの複雑さ: インデックスが増えると、監視、分析、およびメンテナンスの対象となるオブジェクトが増えます。データベース管理者は、価値のないインデックスの最適化に時間を費やします。クエリプランナーは評価するオプションが増え、最適ではない実行計画を選択する可能性があります。
コード例
❌ 非準拠：
-- usersテーブル上の冗長なインデックス
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_users_email_status ON users(email, status);
CREATE INDEX idx_users_created ON users(created_at);
CREATE INDEX idx_users_created_status ON users(created_at, status);
-- 単一列インデックスは冗長です。なぜなら
-- 複合インデックスが同じクエリに対応できるからです
誤っている理由： メール上のインデックスは冗長です。なぜなら idx_users_email_status ～で始まる メール そしてメールアドレスのみでフィルタリングするクエリを処理できます。同様に、 idx_users_created と重複しています idx_users_created_status。このテーブルへの挿入または更新ごとに、2つで十分なところを4つのインデックスが更新されます。
✅ 準拠済み:
-- usersテーブル上の最適化されたインデックス
CREATE INDEX idx_users_email_status ON users(email, status);
CREATE INDEX idx_users_created_status ON users(created_at, status);
-- 複合インデックスは、そのプレフィックス列に対するクエリに対応できます
-- emailのみのクエリはidx_users_email_statusを使用します
-- created_atのみのクエリはidx_users_created_statusを使用します
これが重要である理由： 2つの複合インデックスがすべてのクエリパターンに対応し、冗長性を排除します。～でフィルタリングするクエリ メール 単独で最初のインデックスを使用し、クエリは以下でフィルタリングされます。 created_at 単独で2番目のインデックスを使用します。4つのインデックスではなく2つのインデックスのみを更新すればよいため、書き込みパフォーマンスが向上します。
まとめ
冗長なものを特定するために、データベースインデックスを定期的に監査してください。他のインデックスのプレフィックスであるインデックスや、カバレッジが重複しているインデックスは削除します。複合インデックスは、その先頭列に対するクエリに対応できるため、ほとんどの場合、個別の単一列インデックスは不要になります。
