看似相同的字符串为何导致SQL查询执行失败？

这种情况我在日常排查数据库问题时碰到过好多次，表面上一模一样的字符串，背后往往藏着容易被忽略的细节，咱们来拆解可能的原因：

最常见的元凶：不可见控制字符 #

很多时候，字符串里会混入零宽空格（U+200B）、**不换行空格（U+00A0）**或者其他非打印控制字符，这些字符肉眼完全看不到，但会让数据库判定两个字符串不相等。比如你第一次输入的ID可能不小心带了这类隐形字符，而从表中复制的是数据库存储的原始干净值，所以查询成功。

你可以用数据库的字符处理函数快速验证：

• 对比两个字符串的长度：SELECT LENGTH('你第一次写的ID') 和 SELECT LENGTH('从表复制的ID')，如果长度不一样，肯定存在额外字符。
• 转成十六进制看编码：SELECT HEX('你的ID')，两个ID的十六进制结果会有明显差异，比如零宽空格的十六进制是E2808B，一眼就能识别。

全角/半角字符的编码陷阱 #

另一种常见情况是全角与半角字符的混淆：比如下划线，半角下划线是_（ASCII编码0x5F），全角下划线是＿（Unicode编码0xFF3F），肉眼几乎无法区分，但数据库会把它们当成完全不同的字符。如果你的第一个查询里用了全角字符，自然匹配不到表中的半角ID。

首尾隐藏的空白字符 #

有时候字符串的开头或结尾会混入空格、制表符（Tab）这类空白字符，你肉眼可能没注意到，但数据库的精确匹配会因为这些额外空格导致失败。复制表中的值时，这些空白不会被带过来，所以查询就正常了。

总结 #

你遇到的情况大概率是以上几种原因之一——隐形控制字符、全角/半角编码差异，或者隐藏的空白字符，导致两个字符串外观一致但实际内容不同。用长度对比、十六进制转码的方法，就能快速定位出具体差异。

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