一个简单的例子，如代码清单1所示。
1: SELECT *
2: FROM HumanResources.Employee
3: WHERE NationalIDNumber = 243322160
4:
5: SELECT *
6: FROM HumanResources.Employee
7: WHERE NationalIDNumber = '243322160'
代码清单1.
NationalIDNumber列定义是Nvarchar，而参数第一个为INT类型，第二个为Varchar类型。那么就存在隐式转换，由高继伟提到的数据类型转换优先级（https://msdn.microsoft.com/zh-cn/library/ms190309.aspx）可以看到，第一列Nvarchar和INT属性类型，INT数据类型优先级高，需要把列NationalIDNumber转换为INT类型，因此涉及到需要把所有该列值转换为INT，因此只能通过扫描操作，从而影响性能。
而代码清单1中第二个查询，NationalIDNumber列为Nvarchar类型，而参数为varchar类型，根据数据类型优先级，需要将Varchar转换为Navrchar，因此仅仅需要对参数进行隐式转换，因此不影响性能。
如何在出现问题之前找到出问题的查询？
在SQL Server中，执行计划会被缓存起来，以便后续进行复用。SQL Server提供了一系列DMV可以查看这些执行计划。由于执行计划的本质是XML，因此通过XQUERY查询特定的执行计划变为可能。
在执行计划中，存在隐式转换的节点会存在类似如代码清单2所示的字段：
1: <Convert DataType="int" Style="0" Implicit="true">
2: <ScalarOperator>
3: <Identifier>
4: <ColumnReference Database="[AdventureWorks2012]" Schema="[HumanResources]" Table="[Employee]" Column="NationalIDNumber" />
5: </Identifier>
6: </ScalarOperator>
7: </Convert>
代码清单2.对列进行转换的执行计划片段
前面提到，只有对列而不是参数进行隐式转换时，才会影响性能。而在代码清单2中对列进行隐式转换的执行计划会引用具体的数据库名称、架构名称、表名称、列名称。而对参数进行隐式转换的仅仅是引用参数，如代码清单3所示。
1: <Convert DataType="nvarchar" Length="8000" Style="0" Implicit="true">
2: <ScalarOperator>
3: <Identifier>
4: <ColumnReference Column="@1" />
5: </Identifier>
6: </ScalarOperator>
7: </Convert>
