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 并不意味着它没有在寻找 MANY 行。

如果您看到 Scan，则表示它从索引的开头开始并从那里开始扫描。从某种意义上说，Index Seek 仍然可以“扫描”；它只是从索引中的精确位置开始。

无论哪种方式，您为什么希望 Scan over a Seek？

于 2012-07-14T20:43:50.203 回答
1

正如我在评论中已经提到的那样：您为什么担心获得索引搜索？

ix_Col1_Col2您的索引Col_1包含Col_2作为包含列，并且还包含Sno来自聚集索引 - 因此它包含您需要满足查询的所有三列。

所以最后，查询优化器选择了如何处理这个查询——它似乎更喜欢索引搜索——我根本看不出有任何问题。

在我的 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.

所以很明显，两者之间几乎没有任何区别 - 可能有一个微小的细节使查询优化器更喜欢索引搜索而不是扫描。不知道为什么 - 但我没有看到任何问题或问题。你？

于 2012-07-14T20:55:07.403 回答