1

私はクエリの下で実行していますが、テーブルからほぼすべてのレコードを返すため、シークではなくインデックススキャンを使用する必要があります。誰でも、スキャンではなくシークを使用している理由を説明してください。


DROP TABLE tblPlanDiff
GO
CREATE TABLE tblPlanDiff(Sno int identity,Col_1 int,Col_2 int)
GO
DECLARE @i int=1
WHILE(@i<=200000)
BEGIN
BEGIN TRAN
INSERT INTO tblPlanDiff values(@i*2,@i*3)
COMMIT TRAN
SET @i+=1

END
CREATE UNIQUE CLUSTERED INDEX ix_Sno on tblplandiff(Sno ASC)
GO
CREATE INDEX ix_Col1_Col2 on tblplandiff(Col_1) INCLUDE(Col_2)
GO
SELECT sno,col_1,col_2 FROM tblPlanDiff
WHERE col_1>2

4

2 に答える 2

1

にインデックスがあるためCol_1、そのインデックス内でCol_1値が 2 より大きいポイントまでシークできます。シークを実行しているからといって、多くの行をシークしていないわけではありません。

スキャンが表示されている場合は、インデックスの先頭からスキャンが開始され、そこからスキャンされていることを意味します。ある意味では、インデックス シークは依然として「スキャン」する可能性があります。インデックス内の正確な位置から開始するだけです。

いずれにせよ、なぜ Seek よりも Scan が必要なのですか?

于 2012-07-14T20:43:50.203 に答える
1

コメントで既に述べたように、インデックス シークを取得することをなぜ心配しているのですか?

インデックスix_Col1_Col2にCol_1はCol_2、含まれる列として含まれておりSno、クラスター化インデックスからも含まれているため、クエリを満たすために必要な 3 つの列すべてが含まれています。

したがって、最終的に、クエリ オプティマイザーはこのクエリにどのようにアプローチするかを選択します。インデックス シークを優先したようです。これにはまったく問題はありません。

SQL Server 2008 R2 Developer エディションでこのクエリを実行すると、次のパフォーマンス値が得られます。

Table 'tblPlanDiff'. 
Scan count 1, logical reads 797, physical reads 3, read-ahead reads 499, 

SQL Server Execution Times: CPU time = 47 ms,  elapsed time = 855 ms.

WITH (FORCESCAN)クエリ ヒントを使用して同じクエリを実行すると、次のようになります。

Table 'tblPlanDiff'. 
Scan count 1, logical reads 797, physical reads 3, read-ahead reads 499, 

SQL Server Execution Times: CPU time = 78 ms,  elapsed time = 852 ms.

したがって、明らかに、この 2 つの間にほとんど違いはありません。また、クエリ オプティマイザーがスキャンよりもインデックス シークを優先するようになった小さな詳細があった可能性があります。理由はわかりませんが、問題や問題は見られません。あなたは？

于 2012-07-14T20:55:07.403 に答える