DB2中LikesBabble表user字段查询异常问题求助

嘿，这个问题我碰到过好几次，大概率是下面这几个原因导致的，咱们一个个排查：

一、最可能的元凶：user是数据库的保留关键字 #

几乎所有主流数据库（比如MySQL、PostgreSQL）里，user都是内置的关键字或者函数——比如MySQL里的USER()函数会返回当前连接的用户名，格式类似root@localhost。当你写WHERE user = 'student_1'的时候，数据库压根没把user当成你表的字段，而是直接调用了这个内置函数，拿函数返回的系统用户名和student_1比，自然查不到结果。

怎么验证？ #

跑个简单的查询对比下就知道：

SELECT user, USER() FROM LikesBabble LIMIT 1;

如果第一列是你表中存的student_1，第二列是类似root@localhost的系统用户名，那百分百是这个问题。

解决办法： #

查询的时候用反引号（`）把字段名包起来，明确告诉数据库这是你的表字段：

SELECT * FROM LikesBabble WHERE `user` = 'student_1';
SELECT * FROM LikesBabble WHERE `user` LIKE '%e%';

长远来看，建议把字段名改成username或者user_id这种不碰关键字的名字，省得以后再踩坑。

二、字段值藏了不可见字符或者编码出问题了 #

如果上面的方法没用，那可能是你存的user值压根不是纯纯的student_1——比如后面带了空格、制表符，甚至是零宽度空格这种肉眼看不到的字符；或者是字符编码不匹配，比如把全角的ｅ或者１存进去了，看起来和半角的一样，但实际是不同字符。

怎么验证？ #

1. 先查字段长度，看看是不是比预期的长：

SELECT user, LENGTH(user) FROM LikesBabble WHERE user LIKE '%student%';

student_1正常长度是8，如果返回的长度大于8，说明肯定藏了额外字符。

2. 查十六进制编码，看字符是不是正常：

SELECT user, HEX(user) FROM LikesBabble WHERE user LIKE '%student%';

正常的student_1十六进制是73747564656E745F31，要是结果和这个不一样，那就是编码或者特殊字符的问题。

解决办法： #

• 要是空白字符的话，用TRIM()清理一下数据就行：

UPDATE LikesBabble SET `user` = TRIM(`user`);

• 要是编码问题，得先检查数据库和客户端的字符集设置（确保都用UTF-8这类统一编码），然后重新插入或者更新正确的字符。

三、概率较低的情况 #

• 大小写敏感问题：如果数据库是区分大小写的，你存的是Student_1但查的是student_1，不过这种情况LIKE '%e%'应该能查到，所以可能性不高。
• 索引损坏：虽然其他字段查着正常，但user字段的主键索引要是坏了，也可能导致查询异常，可以试试重建索引：

ALTER TABLE LikesBabble DROP INDEX `PRIMARY`;
ALTER TABLE LikesBabble ADD PRIMARY KEY (`user`, babble);

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