SQL Server 2005にストアドプロシージャがあり、それを実行して実行プランを見ると、クラスター化インデックススキャンを実行していることがわかります。これには、84%のコストがかかります。Clustered Index Seekを取得するには、いくつか変更する必要があることを読みましたが、何を変更すればよいかわかりません。
私はこれでどんな助けにも感謝します。
ありがとう、
ブライアン
SQL Server 2005にストアドプロシージャがあり、それを実行して実行プランを見ると、クラスター化インデックススキャンを実行していることがわかります。これには、84%のコストがかかります。Clustered Index Seekを取得するには、いくつか変更する必要があることを読みましたが、何を変更すればよいかわかりません。
私はこれでどんな助けにも感謝します。
ありがとう、
ブライアン
詳細がないと、問題が何であるか、さらには問題であるかどうかを推測するのは困難です。シークの代わりにスキャンを選択することは、多くの要因によって引き起こされる可能性があります。
SELECT * FROM <table>
です。これは些細なケースであり、他に何も考慮する必要がなく、クラスター化されたインデックススキャンで完全にカバーされます。WHERE column = @value
が、列はVARCHAR
(Ascii)で、@ valueはNVARCHAR
(Unicode)です。(foo, bar)
が、WHERE句はbar
単独でオンになっています。これらは、クラスター化インデックスのシークが予想されるときにクラスター化インデックススキャンが存在する理由のいくつかの簡単な指針です。質問は非常に一般的であり、8ボールに頼る以外に「なぜ」と答えることは不可能です。ここで、質問が適切に文書化され、明確に表現されているとすると、クラスター化インデックスのシークを期待するということは、クラスター化されたキー値に基づいて一意のレコードを検索していることを意味します。この場合、問題はWHERE句のSARGabilityにある必要があります。
クエリにテーブル内の行の特定の割合以上が含まれている場合、オプティマイザはシークの代わりにスキャンを実行することを選択します。これは、その場合に必要なディスクIOが少なくなると予測するためです(シークの場合は、1つ必要です)。返される各行のインデックスのレベルごとのディスクIO)、スキャンの場合、テーブル全体の行ごとに1つのディスクIOのみがあります。
したがって、たとえばbツリーインデックスに5つのレベルがある場合、クエリによってテーブル内の行の20%以上が生成される場合、20%ごとに5つのIOを作成するよりも、テーブル全体を読み取る方が安価です。行...
プロセスのこのステップで返される行数を減らすために、クエリの出力をもう少し絞り込むことができますか?これは、スキャンよりもシークを選択するのに役立ちます。