导读:此文章主要向大家描述的是正确的隐式转换与SQL Server数据库的相关性能问题，面临的问题可以对其通过在HumanResources.Employee表的SQL Server 2005 AdventureWorks数据库中做一个类似的查询来看到。

为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么，让我们来查找IO统计数据，

我面临的问题可以通过在HumanResources.Employee表的SQL Server 2005 AdventureWorks数据库中做一个类似的查询来看到。为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么，让我们来查找IO统计数据，并且使用SSMS菜单命令Query/Include Actual Execution Plan。

为了使用AdventureWorks数据库并且启用IO统计数据，让我们从下面的查询开始：

use AdventureWorks   go  SET STATISTICS IO ON  go

这是对Employee表的一个查询，它类似于给我带来上述麻烦的查询：

SELECT EmployeeID, NationalIDNumber, LoginID   FROM HumanResources.Employee  WHERE NationalIDNumber = 112457891 go

它看起来似乎不会给我们带来什么麻烦。HumanResources.Employee表有一个以NationalIDNumber开始的索引，因此执行这个查询只是查找112457891的位置然后对这个表的行作查找。但是统计数据和查询计划显示了事情并非如此简单。这是相关的信息：

EmployeeID NationalIDNumber LoginID   4 112457891 adventure-works/rob0  (1 row(s) affected)  Table 'Employee'. Scan count 1, logical reads 6,  physical reads 0, read-ahead reads 0,  lob logical reads 0, lob physical reads 0,  lob read-ahead reads 0.  (1 row(s) affected)

该统计数据显示有一个扫描，而这正是问题所在。Adventureworks.HumanResources.Employee只有291行，因此这可能真的可以很快地运行并且看似不会造成什么问题。我使用的表有数百万行，表扫描正是凶手，因为它对于每次查询都要花几秒的时间。