SQL SERVER中LIKE在Char和nChar输出结果不一致解惑

一同事在写脚本时，遇到一个关于LIKE里面使用不同的变量类型导致查询结果不一致的问题，因为这个问题被不同的人问过好几次，索性总结一下，免得每次都要解释一遍，直接丢一篇博客岂不是更方便！其实看似有点让人不解的现象背后实质跟数据类型的实现有关。

下面我们构造这样一个类似的简单案例。如下所，

CREATE TABLE TEST
(ID        INT IDENTITY(1,1),
 NAME    VARCHAR(32)
)
 
INSERT INTO dbo.test
SELECT 'abc32'
 
INSERT INTO dbo.test
SELECT 'abd32'
 
INSERT INTO dbo.test
SELECT 'abe32' 
 
 
 
 
DECLARE @name  VARCHAR(32);
SET @name='ab%';
SELECT * FROM TEST WHERE NAME LIKE @name;
 
 
DECLARE @name1 CHAR(32);
SET @name1='ab%';
SELECT * FROM dbo.TEST WHERE NAME LIKE @name1;

如上截图所示，当变量使用VARCHAR类型与CHAR类型时，两种的输出结果完全不一样。如果对SQL SERVER数据类型了解不透彻的话，估计真的对这个问题感到相当困惑。但是对SQL Server数据类型了解比较深入的人来说，这真的是一个简单到不能再简单的问题。

如下所示，我们在SQL语句中加入两句SQL，用DATALENGTH返回任何表达式的字节数，你会发现VARCHAR类型的变量返回的字节数为3，但是CHAR类型的变量的字节数为32，其实原因就在于CHAR类型是定长的，也就是当你输入的字符小于你指定的数目时，例如char(32)，你输入的字符小于32时，它会在后面补空值。当你输入的字符大于指定的数时，它会截取超出的字符. 所以下面两种LIKE的逻辑意义不一样。LIKE 'ab%' 与 LIKE 'abc% '的逻辑完全不同。

其实你想从侧面印证一下也很简单，如下脚本对比所示，仔细理解一下，也许你就想明白了！

DECLARE @name  CHAR(32);

SET @name='ab%';

SELECT * FROM TEST WHERE NAME LIKE @name;

 

 

DECLARE @name1 CHAR(3);

SET @name1='ab%';

SELECT * FROM dbo.TEST WHERE NAME LIKE @name1;

以下示例将本地 char 变量传递给存储过程，然后使用模式匹配来查找其姓氏以一组指定的字符开始的所有雇员。

-- Uses AdventureWorks  

CREATE PROCEDURE FindEmployee @EmpLName char(20)  
AS  
SELECT @EmpLName = RTRIM(@EmpLName) + '%';  
SELECT p.FirstName, p.LastName, a.City  
FROM Person.Person p JOIN Person.Address a ON p.BusinessEntityID = a.AddressID  
WHERE p.LastName LIKE @EmpLName;  
GO  
EXEC FindEmployee @EmpLName = 'Barb';  
GO

因为尾随空格是有意义的，所以此过程失败。

但以下示例会成功，因为没有向 varchar 变量中添加尾随空格。

-- Uses AdventureWorks  

CREATE PROCEDURE FindEmployee @EmpLName varchar(20)  
AS  
SELECT @EmpLName = RTRIM(@EmpLName) + '%';  
SELECT p.FirstName, p.LastName, a.City  
FROM Person.Person p JOIN Person.Address a ON p.BusinessEntityID = a.AddressID  
WHERE p.LastName LIKE @EmpLName;  
GO  
EXEC FindEmployee @EmpLName = 'Barb';

FirstName      LastName            City
----------     -------------------- --------------- 
Angela         Barbariol            Snohomish
David          Barber               Snohomish
(2 row(s) affected)

https://www.cnblogs.com/kerrycode/p/9069910.html

https://docs.microsoft.com/zh-cn/sql/t-sql/language-elements/like-transact-sql?view=sql-server-2017