>查询表示覆盖整个表的结果集. IE浏览器.查询是一个简单的SELECT * FROM< table>.这是一个简单的案例,可以通过一个简单的索引扫描完全覆盖,而无需考虑其他任何事情.
>优化器没有其他选择：

>查询表示整个表的子集,但过滤谓词位于不属于群集键的列上,并且这些列上也没有非clustred索引.除了完整扫描之外,这些都不是替代计划.
>查询在clustred索引键中的列上有过滤谓词,但它们不是SARGable.过滤谓词通常需要重写以使其成为SARGable,正确的重写取决于具体情况.由于隐式转换规则,可能会出现更微妙的问题,例如.过滤谓词是WHERE column = @value但是列是VARCHAR(Ascii)而@value是NVARCHAR(Unicode).
>查询在群集密钥中的列上具有SARGale过滤谓词,但不过滤最左侧的列. IE浏览器. clustred index位于列(foo,bar)上,但WHERE子句仅在bar上.

>优化器选择扫描.

>当替代方案是非聚集索引然后扫描(或范围搜索)但是选择是使用聚簇索引时,由于缺少查询投影的非聚集索引覆盖,原因通常可以追溯到index tipping point .请注意,这不是您的问题,因为您期望聚集索引搜索,而不是非聚集索引搜索(假设问题是100％准确并记录…)
>基数估计.查询成本估计基于聚集索引关键字统计信息,该统计信息提供结果基数的估计(即,将匹配多少行).在一个简单的查询中这不可能发生,因为搜索或范围搜索的任何估计都将低于扫描的估计,无论统计数据有多少,但是在复杂查询上,在多个表上都有连接和过滤器,事物更复杂,并且计划可能包括预期搜索的扫描,因为查询优化器可以选择计划,其中连接评估顺序与观察者期望的相反.反向顺序选择可能是正确的(大多数情况下)或可能有问题(通常由于统计数据已过时或参数嗅探).
>订购保证.扫描将以保证的顺序产生结果,并且执行树上更高的元素可以从该顺序中受益(例如,可以消除排序或假脱机,或者可以使用合并连接而不是散列/嵌套连接).总体而言,由于选择明显较慢的访问路径,查询成本更好.

这些是一些快速指针,指出在预期聚簇索引搜索时可能存在聚簇索引扫描的原因.这个问题非常通用,除了依靠8球之外,不可能回答’为什么’.现在,如果我将您的问题正确记录并正确表达,那么期望聚集索引寻找它意味着您正在根据已确定的键值搜索唯一记录.在这种情况下,问题必须与WHERE子句的SARGability有关.