MySQL存储数据乱码的问题解析

mysql的字符集设置有多个层级,在mysql中存储中文,如果不能正确设置字符集,很容易出现数据乱码。今天就有一个用户反馈他数据库中的数据下午1点多开始出现了乱码。在这里,我分享下具体问题的排查过程,以及解决的办法。

(1)  排除客户端设置导致的显示乱码

如果用户设置的mysql character_set_client跟客户端显示的字符集不一致,很容易导致中文数据乱码。

设置session字符集为utf8:set names utf8,设置客户端显示字符集为utf8,然后从表中select出有乱码的数据。

上面显示,在character_set_client跟客户端的字符集一致的情况下,还是出现了乱码,这个排除是用户显示字符集设置不对的可能。下面通过hex(item_title)列来查看这个列在底层的存储字符集是否正确。

通过上面的查询,可以确认这个数据乱码不是显示问题,而是存储的数据内容本身就是错误的。

(2)  定位存储乱码原因

1>     用户确认这个记录插入时能够正常显示,但是后来update之后,数据就乱码了。根据这个信息到binlog中查找更改正确内容对应的update语句。

上面的binlog日志显示这个sql将原来数据库中正确的内容,更新成一堆乱码。所以导致数据库中的存储数据乱码。

从binlog日志可以看出在更新时,是用latin1的方式写入到数据库中。Update后面的set语句中item_title字段的内容是乱码的,所以确认是导入数据源本身内容有问题,从而导致更新后的数据乱码。跟用户确认这个update语句的更新内容,是先从库中load 出来,后拼接成的update sql,所以怀疑load出来的数据就已经是乱码了,然后直接用这个错误的数据更新原来正确的数据,导致所有的正确的数据乱码。所以,需要确认这个update导入的数据源是否正确,即load出来的数据是否是正确的。

2>     导入数据源确认

开启实例的全日志开关,然后比对日志,从上面update语句对应的连接运行的sql中查找数据导出语句,以及对应的字符集设置。

从上面的日志内容可以看出,这个连接建立后没有进行任何字符集的设置,直接从数据库中将内容select出来。在mysql中,如果没有设置session级别的字符集,那么使用默认的配置,配置如下:

即输出会按照latin1的格式显示。在默认字符集的配置下,手动运行SELECT `main_table`.* FROM `promo_item` AS `main_table` WHERE  promo_item_id ='500186324' 命令,可以发现,在character_set_results 设置为latin1的情况下,输出结果中的item_title确实为一堆问号。

由于latin1不能正确表示中文字符,所以显示为一堆问号,用户直接将这个内容update 原来正确的内容,所以导致存储内容乱码。

(3)小结

在使用mysql存储中文字符时,需要注意以下几点:

1>     确认更新的数据源同mysql 的session级别的字符集保持一致,Session级别的字符集可以用set names charset_name来设置。

2>     如果要正确显示中文,需要将character_set_results设置为GBK或是utf8。同时,客户端的显示字符集需要跟character_set_results的配置一致。

以上是 MySQL存储数据乱码的问题解析 的全部内容, 来源链接: utcz.com/z/334325.html

回到顶部