为什么索引查找而不是扫描 SQL Server 2005 中的以下设置答案

【问题标题】：Why index seek and not a scan for the following setup in SQL Server 2005为什么索引查找而不是扫描 SQL Server 2005 中的以下设置
【发布时间】：2012-04-21 02:40:48
【问题描述】：

我已经创建了一个表

create table #temp(a int, b int, c int)

我在这张表上有 2 个索引：

c 上的非聚集非唯一索引
a 上的聚集索引

当我尝试执行以下查询时：

select b from #temp where c = 3

我看到系统进行索引扫描。这很好，因为非聚集索引没有 b 作为键值。因此，它从 a 列进行索引扫描。

但是当我尝试执行以下查询时：-

select b from #temp where c= 3 and a = 3

我看到执行计划只有索引搜索。没有扫描。这是为什么呢？

聚簇索引和非聚簇索引都不是 b 作为列之一吗？

我希望进行索引扫描。

请澄清

【问题讨论】：

您为什么希望进行索引扫描？

标签： tsql sql-server-2005

【解决方案1】：

如果您将 a 作为集群键，则该列将包含在该表的所有非集群索引中。

所以c 上的索引也包括a，所以条件

where c= 3 and a = 3

可以使用索引查找在该索引中找到。最有可能的是，查询优化器决定进行索引查找以查找 a 和 c 并通过键查找来获取其余数据比使用索引扫描更快/更有效。

顺便说一句：您为什么期望/更喜欢索引扫描而不是索引搜索？索引搜索通常更快并且使用更少的资源 - 我总是会努力通过扫描获得索引搜索。

【讨论】：

+1。发现。我认为张贴者在问为什么它可以寻找而不是他们想要扫描（这就是我最初解释这个问题的方式）
+1 只是为了补充几点。 (1) 对于非唯一非聚集索引，CI 键被添加到 NCI 键中，而不是作为包含列。 (2) 据推测，附加条件所暗示的附加选择性使得它更喜欢寻找更少的查找。

【解决方案2】：

这很好，因为非聚集索引没有 b 作为键值。因此，它从 a 列进行索引扫描。

这个假设是不正确的。索引查找和扫描必须处理 WHERE 子句而不是 select 子句。

现在你的问题 -

where子句被sql优化器优化，因为有a=3的条件，所以可以应用聚集索引。

【讨论】：