T-SQL等值查询无结果但LIKE通配符可匹配数据的问题咨询
问题成因结论
这个现象和T-SQL类型推断、SQL Server隐藏特性没有任何关系,不存在字符数字混合干扰类型判断的情况——比较的字段和查询常量都是varchar类型,全程不会触发隐式类型转换。问题本质是对查询语义的理解偏差+实际存储值和预期不一致,具体逻辑如下:
- 首先明确两个查询的语义差异:
- 等值查询
casenumber = '21-CR-1019'要求字段值和右侧常量完全逐字符匹配、长度完全一致才会返回结果 - 前后带通配符的LIKE查询
casenumber like '%21-CR-1019%'属于模糊包含匹配,只要求字段值任意连续位置包含21-CR-1019这个子串就会返回结果,子串前后允许存在任意长度(包括0长度)的其他字符
- 等值查询
- 你自己的校验结果已经给出了核心证据:查询返回的
casenumber实际存储值是2021-CR-1019,长度为12。你等值查找的常量21-CR-1019长度仅为10,两个值长度、内容都不相同,等值查询必然返回空。 - 而
2021-CR-1019从第3个字符开始的连续10位,刚好就是21-CR-1019:
这个值完全符合位置: 1 2 3 4 5 6 7 8 9 10 11 12 字符: 2 0 2 1 - C R - 1 0 1 9 ↑-------------------↑ 这一段刚好匹配'21-CR-1019''%21-CR-1019%'的匹配规则,自然会被模糊查询返回。
验证方法
你可以直接执行如下语句确认两个值的匹配逻辑,返回结果会和你之前遇到的现象完全一致:
SELECT CASE WHEN '2021-CR-1019' = '21-CR-1019' THEN '相等' ELSE '不相等' END AS EqualCheck, CASE WHEN '2021-CR-1019' LIKE '%21-CR-1019%' THEN '匹配' ELSE '不匹配' END AS LikeCheck
排查建议
目前从返回结果看,字段不存在不可见字符、空格填充之类的存储异常,你可以检查两个方向:
- 是不是等值查询的条件写错了,漏了案号前缀的
20,实际要查的就是2021-CR-1019 - 如果业务上确实应该存在
21-CR-1019这个案号,需要排查业务写入逻辑,确认对应数据是否未正确入库
内容的提问来源于stack exchange,提问作者504more
相关产品推荐
相关产品推荐

