代码接受实体类字段对应全部错误 其实这种情况严格意义上不能说是查询结果不一致，比如我们将查询出的结果集用一个 **List ** 接受，我们可能会发现这个列表的 size 是大于 0 的，但是列表中不存在任何元素，那就要考虑是否字段对应关系出现了问题，Mybatis默认使用驼峰式匹配。

查看程序中的Mysql链接字符串是否添加了编码格式 jdbc:mysql:// ${DBURL:localhost}: ${DBPORT:3306}/aaa?useUnicode=true&rewriteBatchedStatements=true&characterEncoding=utf8&serverTimezone=GMT%2B8

查看数据库的编码 show VARIABLES like 'char%' 一般情况下都是 utf8(utf8mb3) 或者 utf8mb4 如果不是找到mysql安装路径，修改配置文件并重启服务

查看 general log ，确认本地执行的语句和程序中执行的语句是否一致，并确认数据库中的数据正确性 general log 比 binlog 要轻量，开启 general log 的方法可以自行搜索，我们开启之后执行程序查询并找到我们执行的语句 我在执行后打印的日志中，有一行 SET NAMES utf8 ； ~ 然后我把这一句在本地执行时也加上了 例如之前 select * from a where name =‘测试’ ; 是有记录的 但是执行 set names utf8 ; select * from a where name =‘测试’ ; 查询结果就是空的 ~ 显然就是这个编码设置导致查询结果异常，说明数据库中的数据不是用 utf8 格式存储的，一般查询条件中存在中文时会出现查询结果对不上的情况 因为字母和阿拉伯数字不管是在 latin 还是 utf8 以及 gbk 编码中都是一样的 ~ 再确认一下上面的推断，我们根据其他字段选择测试这行数据，并打印 “测试” 的编码值： 执行 select HEX(name) from a where id ='测试的ID’ 正常数据 异常数据 一个中文在 mysql 中以 utf8 存储时占用三个字节，因此我们可以看到第一张图的结果是字节长度是正常的。 说明推断是正确的，继而找数据编码错误的原因

确认自己使用的SQL管理工具没有特殊设置 在按照上面第三条修改了数据库配置之后，可能发现show VARIABLES like ‘char%’，仍然和原来一样 或者正如第四条中一样，数据不是 utf8 格式的 那么就有可能是SQL管理工具在搞鬼，我是用的是 Navicat ，数据是通过 数据传输 功能从其他数据库中同步过来的。 ~ 其中数据库连接中有个配置，如下 这个地方一般不要修改，选择自动就行，就是这里不知道什么时候设置了不正确的编码导致数据同步的数据保存的格式有问题。

确认查询的结果集确实是有内容的 有一些情况下，我们会用到关联查询，比如： select b. * from a left join b on a.id =b.id where a.id=1 但是实际情况是，我们能够在 a 表中查询到相关行，但是在b表中没有该行对应的信息，也就表示我们查询的b.*中的字段全是null值。 在程序 中可能就会体现为查询到了记录，但是记录中的值都是空的。