该统计数据显示有一个扫描，而这正是问题所在。Adventureworks.HumanResources.Employee只有291行，因此这可能真的可以很快地运行并且看似不会造成什么问题。我使用的表有数百万行，表扫描正是凶手，因为它对于每次查询都要花几秒的时间。
由于NationalIDNumber字段在索引以及该索引唯一字段的开头，那么为什么这里只有一个扫描而没有查找呢?下面的查询机坏昂告诉我们为什么。这是你可以看到索引扫描的整个计划：
图一
该索引扫描的工具技巧给出所有不同点的详细信息，如下所示：
图二
红色箭头指向了该问题。函数CONVERT_IMPLICIT(int, [AdventureWorks].[HumanResources].[Employee].[NationalIDNumber, 0)在它与我们传递到该查询中的整数常数1124579811比较之前修改了NationalIDNumber字段。如果你查看这张表的定义，那么你就会看到NationalIDNumber被定义成nvarchar(15)。一旦这里有个函数，即使是我们在这里看到的自带函数用于这个字段，SQL Server都不能在NationalDNumber上使用索引，它会返回到一个扫描中。
