此文章主要向大家描述的是正确的隐式转换与SQL Server数据库的相关性能问题，面临的问题可以对其通过在HumanResources.Employee表的SQL Server 2005 AdventureWorks数据库中做一个类似的查询来看到。
为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么，让我们来查找IO统计数据，
我面临的问题可以通过在HumanResources.Employee表的SQL Server 2005 AdventureWorks数据库中做一个类似的查询来看到。为了帮助我们更好地理解SQL Server在我们运行这些查询时都做了什么，让我们来查找IO统计数据，并且使用SSMS菜单命令QueryInclude 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-worksrob0 (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行，因此这可能真的可以很快地运行并且看似不会造成什么问题。我使用的表有数百万行，表扫描正是凶手，因为它对于每次查询都要花几秒的时间。
由于NationalIDNumber字段在索引以及该索引唯一字段的开头，那么为什么这里只有一个扫描而没有查找呢 下面的查询机坏昂告诉我们为什么。这是你可以看到索引扫描的整个计划：
该索引扫描的工具技巧给出所有不同点的详细信息，如下所示：
红色箭头指向了该问题。函数CONVERT_IMPLICIT(int, [AdventureWorks].[HumanResources].[Employee].[NationalIDNumber, 0)在它与我们传递到该查询中的整数常数1124579811比较之前修改了NationalIDNumber字段。假如你查看这张表的定义，那么你就会看到NationalIDNumber被定义成nvarchar(15)。一旦这里有个函数，即使是我们在这里看到的自带函数用于这个字段，SQL Server数据库都不能在NationalDNumber上使用索引，它会返回到一个扫描中。
更改这个查询来与一个字符串常数比较，这个问题将得到解决：
SELECT EmployeeID, NationalIDNumber, LoginID FROM HumanResources.Employee WHERE NationalIDNumber = '112457891' go
这些信息现在显示为零扫描，这正是我们想要的。在这个案例中，逻辑读的不同点是只有2，这是因为Employee很小。假如在数百万行的表上进行这个过程，那么逻辑读的不同点将变成几千。
EmployeeID NationalIDNumber LoginID 4 112457891 adventure-worksrob0 (1 row(s) affected) Table 'Employee'. Scan count 0, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. (1 row(s) affected)
查询计划显示查找和主键查找正是我们希望看到的。
一个字符串用于存储一个数字型主键的问题是很常见的。SQL Server数据库将很忠实地执行隐式转换并返回正确的结果，但是要以较差的性能为代价，通过一个扫描而不是查找来进行并且要正确使用该索引。
下一步
要一直警惕隐式转换，尤其是有存储数字型键的字符串的时候。
我甚至在varchar字段与nvarchar字段进行比较的时候看到这个问题。
更正这个问题是很简单的，你只需要确保在相似的数据类型上执行比较。