1

私はこのテーブル（TableA）を持っています：

(
    [FieldA] [int] NOT NULL,
    [FieldB] [int] NOT NULL,
    [Value] [float] NULL
CONSTRAINT [PK_TableA] PRIMARY KEY CLUSTERED 
(
    [FieldA] ASC,
    [FieldB] ASC
)

明確なFieldA値はほとんどありません。たとえば、FieldAを{1,2,3,4,5,6}にすることができます。

このクエリによって全表スキャンが発生するのはなぜですか。

SELECT COUNT(*) FROM TableA WHERE FieldB = 1

これはしませんが：

SELECT COUNT(*) FROM TableA WHERE FieldB = 1 where FieldA in (1,2,3,4,5,6)

SQL Serverはこれを最適化できませんか？FieldAがPKであるTableBがあり、TableBとTableAを結合した場合、クエリは2番目のクエリと同様に実行されます。

4

2 に答える 2

1

どうやら、私が探していたのは、Oracleでは利用できるがSQLServerでは利用できないスキップスキャン最適化です。スキップスキャンは、リーディングエッジ列の述語が欠落している場合にインデックスを利用できます： http ：//social.msdn.microsoft.com/Forums/eu/transactsql/thread/48de15ad-f8e9-4930-9f40-ca74946bc401

于 2012-04-11T11:52:12.237 に答える
1

作成したクラスター化インデックスは、2つの列に基づいています。これらの列の1つだけでルックアップを実行している場合、SQL Serverはそのインデックスのルックアッププロセスで使用する「キー」値を生成できないため、テーブルスキャンアプローチにフォールバックします。

FieldAには含まれる可能性のある値の範囲が非常に狭い場合でも、SQLオプティマイザーはその範囲の値を調べて、指定された情報からキーを「ファッジ」できるかどうかを判断しません。

最初のクエリのパフォーマンスを向上させたい場合は、FieldBに別のインデックスを作成する必要があります。あなたが言うように、FieldAに多くの明確な値がなく、ほとんどのルックアップをFieldBで排他的に実行する場合は、クラスター化インデックスをFieldBでのみ構築するように移動し、FieldAで一意のインデックスを生成することを検討してください。 FieldB。

于 2012-03-24T13:13:48.870 に答える