背景
不合适的数据类型隐式转换会导致性能下降和并发下降，而且大多数技术人员对隐式转换的概念是陌生的，因此在生产环境中非常常见，通过本文做一个系统的梳理。
现象
收到SQL专家云阻塞告警邮件，登录SQL专家云，进入实时可视化页面，看到从20点开始出现大量的阻塞。
进入活动会话原始数据页面，看到产生阻塞的都是同一类语句。
SQL语句是很简单的一个MERGE语句，基于表的主键PK_NAME进行匹配，匹配到做更新，匹配不到做插入。
DECLARE @PK_NAME nvarchar(4000), @PK_VALUE nvarchar(4000)MERGE INTOCOIND_DS tUSING(SELECT @PK_NAME AS PK_NAME, @PK_VALUE AS PK_VALUE) bON(t.PK_NAME = b.PK_NAME)WHEN MATCHED THENUPDATE SET PK_VALUE = @PK_VALUEWHEN NOT MATCHED THEN??INSERT?(PK_NAME,?PK_VALUE)?VALUES(@PK_NAME,?@PK_VALUE);
?
分析
?
通过现象发现有两点不正常，第一：基于主键的更新或者插入一条数据，而且各个并发会话的参数值都不一样，不应该产生阻塞；第二：该语句不应该有如此高的CPU消耗时间和读次数。
?
第一反应就是可能存在隐式转换，查看表的PK_NAME字段，是varchar（4000）的数据类型，而参数@PK_NAME是nvarchar(4000)，在进行比较前，通过隐式转换把PK_NAME字段的值转换成nvarchar，导致查找次数增多，读次数和CPU时间增加，最主要的是导致了并发的下降，因此才产生了阻塞。
SQL Server在进行比较、组合、赋值等操作时，要进行数据类型的转换，数据类型转换分为隐式转换和显示转换。隐式转换对用户不可见，?SQL Server根据数据类型优先级规则将优先级较低的数据类型自动转换为优先级较高的数据类型，例如，smallint 会被转换为 int，char会被转换为nchar。如果两种数据类型不支持隐式转换，则返回错误；显式转换使用 CAST 或 CONVERT 函数，CAST 和 CONVERT 函数可将值（局部变量、列或其他表达式）从一种数据类型转换为另一种数据类型，例如，CAST ( $157.27 AS VARCHAR(10) )。
SQL Server官方文档中提供了一张数据类型转换表，详细的描述了各数据类型之间的转换关系，详细请参考：https://learn.microsoft.com/zh-cn/sql/t-sql/data-types/data-type-conversion-database-engine?view=sql-server-2017。
DEMO
首先创建一张表，其中字段id的数据类型varchar，并且为主键、聚集索引。最后写入100万行数据。
?
对字段id做一个简单的LIKE查询，参数@id的数据类型为varchar。通过执行计划看使用聚集索引查找。逻辑读取次数是7次。
?
把参数@id的数据类型改成nvarchar后，通过执行计划可以看到，在比较时要把字段id每行的值从varchar转换成nvarchar，然后再进行比较，从而产生了隐式转换，导致索引查找变成索引扫描，逻辑读取次数从7次增加到1006108次。这仅是一个100万行数据的表，表的行数越多造成的性能影响越大。
?
说明1：这里用LIKE来做演示是因为执行计划简单，容易理解。现实中大多数情况还是等值比较，因为SQL Server做了相关的优化，把nchar类型的值计算为char类型的最小值和最大值，然后进行范围的查找，再对查找出来的结果进行隐式转换后比较，因此是不会导致索引扫描的，性能下降的不是特别厉害，但是由于变成了范围查找，加锁的行数增加了，还是会导致并发下降。
说明2：如果字段是nchar\nvarchar，参数是char\varchar类型，隐式转换的是参数的值，是不影响性能的。
解决
在设计字段类型和声明参数时不要随意，最典型的错误就是在SQL语句中声明字符串参数时不管什么用途一律使用nvarchar类型。
在程序中指明数据类型，例如在C#中不明确指定数据类型的字符串参数，就会使用nvarchar数据类型。
?
想要生成varchar数据类型，一定要明确指定。
?