SQL Serverインデックススキャンとインデックス同じパフォーマンスを持つシーク数

Question

非常に大きなテーブルからカウントを選択しようとすると、今は4つのクエリが入力されています。

クエリは本質的にこれです。

SELECT count(PrimaryKeyIntColumn) from dbo.TableName 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn >= 0 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn IS NOT NULL 

SELECT count(PrimaryKeyIntColumn) from dbo.TableName where PrimaryKeyIntColumn BETWEEN 1 and 2147483647 

私は推定実行プランを表示するために行くとき、私は最初のものは、非クラスタ化インデックススキャン、秒1で見クラスタ化インデックスは、シーク第三は、非クラスタ化インデックスのスキャンであり、第4は、さクラスタ化インデックスシーク。これは多かれ少なかれ予期せぬものです（主キーはすでにヌル可能ではないため、クエリーオプティマイザがおそらく投げ捨てるだけなので、通常はSARGableになりません）

これらの各クエリーはそれぞれ25％クエリのコストは4のバッチに比例し、各インデックススキャンまたはインデックスシークはコストの95％を占めます。基本的に、わかる限り、この特定のシナリオでは、インデックススキャンとインデックスシークの間に実際のパフォーマンスの違いはありません。

正確な実行計画がSELECTである0％ - >計算スカラ0％ - >ストリーム集計5％ - >指数（スキャン|シーク）、95％私は問題が何であるか本当にわからないんだけど

が、シークは走査よりも少し速く見えない。私が辛抱する前にこれらのスピンを数分間実行して、クエリをキャンセルします。

私はカウントを何か他の方法で得ることができると知っていますが、それは本当に最終目標ではありません。私は他のいくつかのクエリでパフォーマンスを落とそうとしていますが、なぜシークにスキャンを回しても何もしません。私はなぜこれが起こっているかを知ることができれば、私は問題の実際の根に到達できるかもしれないと考えます。

ご協力いただければ幸いです。これは、1億以上のデータ行を含む非常に大きなテーブルです。

ここにも同様の質問があります：Poor clustered index seek performance?ですが、私には当てはまりません。

Answer 1

これは実際にシークではありません。あなたはちょうど始まりを探し、そこからレンジスキャンを行います。あなたの範囲は（ほぼ）テーブル全体と同じであるため、実際の違いはありません。この数は、クラスタ化されたインデックスまたは非クラスタ化インデックスのいずれかで100Mのレコードを通過する必要があります。あなたはそれが速いと期待することはできません。そして、いいえ、rowcountはテーブルのために保存されていますあなたは簡単に読むことができます。