varchar(255)字段用=查询无结果但LIKE有效，求解决方法

我之前在项目里碰到过几乎一模一样的情况，当时折腾了好一阵才找到根源，给你几个排查和解决的方向：

• 排查隐藏的不可见字符
  除了你已经排查的普通空格，还有很多其他不可见字符可能搞鬼——比如制表符（\t）、换行符（\n/\r）、零宽度空格（Unicode U+200B这类）。你可以用这两个SQL命令快速验证：

  1. 对比字符长度和实际字节数：

     SELECT UOM, LEN(UOM) AS 字符长度, DATALENGTH(UOM) AS 实际字节数
     FROM 你的表名
     WHERE UOM LIKE '%PK%'
     

     对于varchar类型，LEN()会忽略末尾空格，而DATALENGTH()返回实际存储的字节数，如果两者数值不一致，说明字段里有额外的隐藏字符。
  2. 检查首尾字符的ASCII码：

     SELECT 
       UOM,
       ASCII(SUBSTRING(UOM, 1, 1)) AS 首字符ASCII,
       ASCII(SUBSTRING(UOM, LEN(UOM), 1)) AS 尾字符ASCII
     FROM 你的表名
     WHERE UOM LIKE '%PK%'
     

     正常的'PK'首字符ASCII是80（对应'P'），尾字符是75（对应'K'），如果数值不对，就说明首尾有隐藏字符。

• 验证字符集与排序规则
  有时候数据库的排序规则会影响精确匹配的结果——比如某些区分重音、大小写或者特殊字符等价的规则，可能导致=匹配失效但LIKE不受影响。你可以试试强制指定一个通用的排序规则来测试：

  SELECT *
  FROM 你的表名
  WHERE UOM COLLATE SQL_Latin1_General_CP1_CS_AS = 'PK'
  

  如果这样能查到结果，说明原排序规则是问题所在，你可以考虑修改字段的排序规则，或者查询时指定排序规则。

• 排查字段/表损坏的可能性
  这种情况概率较低，但也不能完全排除。你可以用DBCC CHECKTABLE命令检查表的完整性：

  DBCC CHECKTABLE(你的表名) WITH NO_INFOMSGS, ALL_ERRORMSGS
  

  如果返回错误信息，说明表存在损坏，这时候建议先备份数据，再根据提示进行修复（比如用DBCC CHECKTABLE(你的表名, REPAIR_REBUILD)，但修复前一定要确认备份）。

• 直接查看原始二进制数据
  要是上面的方法都没找到问题，你可以把匹配到的记录转成二进制，看实际存储的内容：

  SELECT UOM, CONVERT(VARBINARY(255), UOM) AS 二进制值
  FROM 你的表名
  WHERE UOM LIKE '%PK%'
  

  正常的'PK'二进制值是0x504B，如果结果里有额外的字节，那就是这些额外字符导致的问题，你可以用REPLACE函数结合对应的字符码来清理，比如如果是制表符（CHAR(9)），就执行：

  UPDATE 你的表名
  SET UOM = REPLACE(UOM, CHAR(9), '')
  WHERE UOM LIKE '%PK%'
  

内容的提问来源于stack exchange，提问作者slevin37