既存のインデックスに新しいインデックスのすべての列が含まれているのに、なぜこの新しいインデックスを作成するとパフォーマンスが大幅に向上したのですか？

LogテーブルとLogItemテーブルがあります。私は両方からいくつかのデータを取得するクエリを書いています。数千がLogsあり、それぞれLogが最大125まで持つことができますLogItems

問題のクエリは複雑なのでスキップしています（誰かが重要だと思うなら、おそらく投稿できるでしょう）が、SSMS推定クエリプランを実行すると、新しい非クラスタ化インデックスによってパフォーマンスが最大100％向上することがわかりました。

Existing Index: Non-clustered
Key Colums (LogItem): ParentLogID, DateModified, Name, DatabaseModified

Query Plan Recommendation
CREATE NONCLUSTERED INDEX [LogReportIndex]
ON [dbo].[LogItem] ([ParentLogID],[DatabaseModified])

楽しみのために、この新しいインデックスを作成してクエリを実行しましたが、驚いたことに、クエリが実行されるまでに10秒以上かかるのに1秒かかりました。

既存のインデックスがこの新しいクエリをカバーすると想定したので、私のクエリは、新しいクエリで使用される列のみに新しいインデックスを作成するとパフォーマンスが向上するのはなぜですか？where句で使用される列の一意の組み合わせごとにインデックスを作成する必要がありますか？

注：これは、SQL Serverが結果をキャッシュしているためだとは思いません。インデックスを作成する前に約25〜30回クエリを実行しました。以下。

インデックス内の列の順序は重要です。フィルタリングにインデックスの列1と4が必要な場合、インデックスは役に立ちません。最初のN個の連続した列でフィルタリングする場合にのみ役立ちます。

これは、インデックスがツリーであるためです。ツリーのすべてのノードを効率的に選択することはできません。これらのノードは、およびのcolumn3 = something異なる値に属する他のすべての場所に散在しているためです。あなたが知っている場合でも、と同様、ツリー内の右の枝を配置すること非常に簡単ではありません。column1column2column1column2

リーディングエッジ指数のは重要なものです。

クエリがインデックスのリーディングエッジによって「カバー」されている限り、効率的です。通常、データベースインデックスはBツリーとして実装され、Bツリーの構造により、検索を特定の順序で実行する必要があるため、複合インデックスのフィールドの順序が重要になります。

「穴」がある場合、たとえばとで検索するがParentLogID、DatabaseModifiedインデックスのみがオンの{ParentLogID, DateModified, Name, DatabaseModified}場合{ParentLogID}、インデックスの一部のみを効率的に利用できます。

（注：一部の{DatabaseModified}DBMSは「スキップスキャン」でその部分を利用できますが、DBMSがそれを実行しても、通常のインデックスアクセスよりもはるかに効率が低下します）。