複合主キー ペア (UserId、PictureId) を使用して、ユーザーのお気に入りの写真を格納するテーブルがあるとします。本では通常、この場合、(UserId, PictureId) に基づく複合インデックスが必要であると書かれています。これは通常、WHERE 句で (UserId=103 AND PictureId=1234) として表示されます。しかし、データベース エンジンは、2 つの列に基づく 2 つの個別のインデックスを別々に使用できるほどスマートである必要があると思います。各インデックスから行番号のセットを取得し、両方のセットに存在するものを見つけるだけです。そうすれば、複合インデックスは必要ありません。
では、実際にデータベース エンジンはそれを実行できるのでしょうか?
2 つの個別の単一列インデックスを使用するメリットはありません。エンジンは、テーブル スキャンを実行した方がよいでしょう。
インデックスを使用するポイントは、アクセスを高速化することです。エンジンが 2 つのインデックスを使用する場合、インデックスの 1 つから少なくとも 1 セットのデータを並べ替え、2 つのインデックスからの結果をマージする必要があります。特に複合インデックスではインデックスのみのスキャンが可能であるため、これは 1 つの複合インデックスだけを読み取るよりもはるかに多くの作業になります。
ほとんどのデータベースエンジンでは、主キーを適用するために複合インデックスが必要になります。このように、それはとにかくあなたが持っているであろう「無料の」インデックスです-なぜそれを心配するのですか？
UserID,PictureIDに2つ目のインデックスを追加することには、（インデックスがオンの場合）いくつかの利点がある場合がありますPictureID。上のクエリUserIDは複合インデックスを使用できますが、を使用したクエリは使用PictureIDできません。
あなたが説明するものは、複合インデックスを使用するよりも大幅に高価になります。
最初に行のセットを最初のインデックスから識別し、次に 2 番目のインデックスから行のセットを識別し、最後に 2 つの間でセット交差を実行する必要があります。
これは、SELECT だけでなく、すべての INSERT/UPDATE およびすべての外部キー チェックに対して支払う価格であることに注意してください。
また、同時実行の問題が関係する場合があります。DBMS の実装方法によっては、1 つの一意の複合インデックスを使用して一意性を強制する方が、2 つの非一意の非複合インデックスを使用して一意性を強制するよりもロックが少なくて済み、簡単になる場合があります。
もちろん、テーブルをクラスタ化する場合、通常、プライマリ インデックスはクラスタリング インデックスでもあり、とにかくすべての列を含むため、インデックスの「並べ替え」部分から何かを除外してもあまり意味がありません。
PRIMARY KEY または UNIQUE 制約は、抽象的で理論的な概念です。
INDEX は、現実世界に存在する実用的な物理的なものです。
実際には、インデックスを使用して PK または UNIQUE 制約を適用できます。ただし、他の手法も使用できます (たとえば、小さなドメインの場合: ビットマップ)。
あなたが説明したユースケースでは、複合インデックスは必要ないと思います。これは、たとえば、特定のユーザー ID のセットと特定の画像 ID のセットに対してクエリを実行する場合に役立ちます。しかし、いつそれが必要になるのでしょうか? 特定の日付範囲内のすべてのユーザーの写真を照会するか、ID で特定の写真を検索する可能性が高くなります。これは、1 つの複合ユーザー ID + 日付インデックスと、別の画像 IDのみのインデックスのインデックス構造を示唆しています。
それは常に、データベース内のレコードの分布と、最も頻繁に実行するクエリの種類によって異なります。