2 番目のインデックスの開始部分の部分キーであるインデックスを作成した場合、検索基準が単純なインデックスと一致する場合、サーバーは単純なインデックスの結果を取得するのにどれくらい速くなりますか?
たとえば、クラスター化されていないインデックス(TransactionDate, ClientID, State) があり、検索条件が のみTransactionDateである場合、 と の 2 番目のインデックスをClientID作成することでどのような検索パフォーマンスが向上しますか? テーブルには、かなり典型的なデータ分布があります。約 1,200 万行、1 日あたり約 160,000 レコードを含む 100 の日付があり、500 のクライアントに分散されています。TransactionDateClientID
インデックスのメンテナンス ( inserts、updates、deletes) とディスク容量の使用は考慮されません。SQLサーバーがインデックスを実装および利用する方法の低レベルの詳細をいただければ幸いです。
複数のインデックスを維持することに関連するオーバーヘッドを気にしないと具体的に述べたので、答えはイエスです。最初のキーのみを検索する場合は、パフォーマンスと速度の点で、キー列が 1 つだけの狭いインデックスの方が、複数の列を含むインデックスよりも優れています。
2番目、3番目のキーのみを検索する場合。次に、インデックスにリストされている最初の列のみが直接シークに使用できるため、インデックススキャンを回避できるため、それを独自のインデックスに配置する方がはるかに優れています。
検索速度のみを考慮するベスト プラクティスは、単一の用語が定期的に検索される場合に、インデックスを 2 つ (または 3 つ) に分割し、各列に独自のインデックスを取得することです。エッジ ケースで複数の述語が使用されている場合でも、エンジンは複数のインデックスを交差させることができます。
注: 定期的に 2 つの述語を検索する場合。これらの検索では、交差する必要がないため、2 つの複合インデックスの方が適しています。
実際の使用法 (つまり、OLTP と OLAP の比較、またはディスク容量の考慮事項によって異なる場合) では、最善のアプローチは異なる場合がありますが、繰り返しますが、それは気にしないとおっしゃいました。
パフォーマンスの向上/速度の向上に対する実際の認識は、まったく知覚できない場合があることに注意してください。しかし、状況によっては、少しでも役に立ちます。 この Microsoft の SQL インデックス パフォーマンス チェックリスト をご覧ください。
追加の更新:
これは、Brad McGehee によるこのテーマに関する非常に優れた記事です。
http://www.sql-server-performance.com/2007/composite-indexes/
たとえば、クラスター化されていないインデックス (TransactionDate、ClientID、State) があり、検索条件が TransactionDate と ClientID のみである場合、TransactionDate と ClientID の 2 つ目のインデックスを作成すると、どのような検索パフォーマンスが得られるでしょうか?
通常はありません。
インデックス(TransactionDate, ClientID)は (格納する必要がないためState) わずかに狭くなりますが、リーフ (およびテーブル行へのポインター) の数は同じままです。したがって、ノードをより緊密にクラスター化しますが、利点はわずかなものになる可能性があります。
追加のインデックスを維持するオーバーヘッドは、ほぼ確実にこの利点を上回ります。また、維持するということは、単に変更するという意味ではなく、キャッシュも意味するため、理論的には追加のインデックスの方が優れている場合でも、単一のインデックスの方が実際の検索パフォーマンスが向上する可能性があります。
ところで、テーブルがたまたまクラスター化されている場合、これによりセカンダリ インデックスがさらに高価になり、望ましくなくなります。
このトピックにまだ慣れていない場合は、SQL インデックスの解剖学をご覧になることを強くお勧めします。いずれにせよ、自分で結論を出す前に、現実的な量のデータを測定することをお勧めします。